I have a callback that is called through a delegate. Inside it I will need to treat the buffer data that arrive from a record procedure. Normally in a unmanaged context I could do a reinterpret_cast on dwParam1 to get the object reference.
But in a manged context how can I cast a DWORD_PTR to a managed object ref?
static void WaveInProc(HWAVEIN hwi, UINT uMsg, DWORD_PTR dwInstance, DWORD_PTR dwParam1, DWORD_PTR dwParam2)
{
ControlLib::SoundDevice^ soudDevice = ?cast_native2managed?(dwParam1);
Here ya go, more or less what gcroot (per my comment above) does:
using namespace System;
using namespace System::Runtime::InteropServices;
// track an object by a normal (not pinned) handle, encoded in a DWORD_PTR
DWORD_PTR ParamFromObject(Object^ obj)
{
return reinterpret_cast<DWORD_PTR>(GCHandle::ToIntPtr(GCHandle::Alloc(obj)).ToPointer());
}
static void WaveInProc(PVOID hwi, UINT uMsg, DWORD_PTR dwInstance, DWORD_PTR dwParam1, DWORD_PTR dwParam2)
{
// unwrap the encoded handle...
GCHandle h = GCHandle::FromIntPtr(IntPtr(reinterpret_cast<void*>(dwParam1)));
try
{
// and cast your object back out
SoundDevice^ x = safe_cast<SoundDevice^>(h.Target);
}
finally
{
// remember to free the handle when you're done, otherwise your object will never be collected
GCHandle::Free(h);
}
}
I'm not a C++/CLI expert but at a glance I don't think this is possible. If it were possible it would be very much unsafe. The basic problem here is that managed references and native pointers are not the same thing and don't support the same set of operations.
What makes me think this is not possible is that managed objects can move around in memory. Garbage collection operations for instance compact and move memory which correspondingly changes the addresses of objects. Hence it's not possible to have a raw pointer / address value of a managed object because any given GC could invalidate it.
This is not strictly true as you can pin an object in memory. But even then I don't think there is a way to get C++ to treat an arbitrary address as a managed handle.
I think a much safer approach would be the following.
Wrap the managed object inside of a native object
Pass the address of the native object throughout your API's
Use reinterpret_cast to get back to the native type and then safely access your managed handle.
Related
Ok, muddling though Stack on the particulars about void*, books like The C Programming Language (K&R) and The C++ Programming Language (Stroustrup). What have I learned? That void* is a generic pointer with no type inferred. It requires a cast to any defined type and printing void* just yields the address.
What else do I know? void* can't be dereferenced and thus far remains the one item in C/C++ from which I have discovered much written about but little understanding imparted.
I understand that it must be cast such as *(char*)void* but what makes no sense to me for a generic pointer is that I must somehow already know what type I need in order to grab a value. I'm a Java programmer; I understand generic types but this is something I struggle with.
So I wrote some code
typedef struct node
{
void* data;
node* link;
}Node;
typedef struct list
{
Node* head;
}List;
Node* add_new(void* data, Node* link);
void show(Node* head);
Node* add_new(void* data, Node* link)
{
Node* newNode = new Node();
newNode->data = data;
newNode->link = link;
return newNode;
}
void show(Node* head)
{
while (head != nullptr)
{
std::cout << head->data;
head = head->link;
}
}
int main()
{
List list;
list.head = nullptr;
list.head = add_new("My Name", list.head);
list.head = add_new("Your Name", list.head);
list.head = add_new("Our Name", list.head);
show(list.head);
fgetc(stdin);
return 0;
}
I'll handle the memory deallocation later. Assuming I have no understanding of the type stored in void*, how do I get the value out? This implies I already need to know the type, and this reveals nothing about the generic nature of void* while I follow what is here although still no understanding.
Why am I expecting void* to cooperate and the compiler to automatically cast out the type that is hidden internally in some register on the heap or stack?
I'll handle the memory deallocation later. Assuming I have no understanding of the type stored in void*, how do I get the value out?
You can't. You must know the valid types that the pointer can be cast to before you can dereference it.
Here are couple of options for using a generic type:
If you are able to use a C++17 compiler, you may use std::any.
If you are able to use the boost libraries, you may use boost::any.
Unlike Java, you are working with memory pointers in C/C++. There is no encapsulation whatsoever. The void * type means the variable is an address in memory. Anything can be stored there. With a type like int * you tell the compiler what you are referring to. Besides the compiler knows the size of the type (say 4 bytes for int) and the address will be a multiple of 4 in that case (granularity/memory alignment). On top, if you give the compiler the type it will perform consistency checks at compilation time. Not after. This is not happening with void *.
In a nutshell, you are working bare metal. The types are compiler directives and do not hold runtime information. Nor does it track the objects you are dynamically creating. It is merely a segment in memory that is allocated where you can eventually store anything.
The main reason to use void* is that different things may be pointed at. Thus, I may pass in an int* or Node* or anything else. But unless you know either the type or the length, you can't do anything with it.
But if you know the length, you can handle the memory pointed at without knowing the type. Casting it as a char* is used because it is a single byte, so if I have a void* and a number of bytes, I can copy the memory somewhere else, or zero it out.
Additionally, if it is a pointer to a class, but you don't know if it is a parent or inherited class, you may be able to assume one and find out a flag inside the data which tells you which one. But no matter what, when you want to do much beyond passing it to another function, you need to cast it as something. char* is just the easiest single byte value to use.
Your confusion derived from habit to deal with Java programs. Java code is set of instruction for a virtual machine, where function of RAM is given to a sort of database, which stores name, type, size and data of each object. Programming language you're learning now is meant to be compiled into instruction for CPU, with same organization of memory as underlying OS have. Existing model used by C and C++ languages is some abstract built on top of most of popular OSes in way that code would work effectively after being compiled for that platform and OS. Naturally that organization doesn't involve string data about type, except for famous RTTI in C++.
For your case RTTI cannot be used directly, unless you would create a wrapper around your naked pointer, which would store the data.
In fact C++ library contains a vast collection of container class templates that are useable and portable, if they are defined by ISO standard. 3/4 of standard is just description of library often referred as STL. Use of them is preferable over working with naked pointers, unless you mean to create own container for some reason. For particular task only C++17 standard offered std::any class, previously present in boost library. Naturally, it is possible to reimplement it, or, in some cases, to replace by std::variant.
Assuming I have no understanding of the type stored in void*, how do I get the value out
You don't.
What you can do is record the type stored in the void*.
In c, void* is used to pass around a binary chunk of data that points at something through one layer of abstraction, and recieve it at the other end, casting it back to the type that the code knows it will be passed.
void do_callback( void(*pfun)(void*), void* pdata ) {
pfun(pdata);
}
void print_int( void* pint ) {
printf( "%d", *(int*)pint );
}
int main() {
int x = 7;
do_callback( print_int, &x );
}
here, we forget thet ype of &x, pass it through do_callback.
It is later passed to code inside do_callback or elsewhere that knows that the void* is actually an int*. So it casts it back and uses it as an int.
The void* and the consumer void(*)(void*) are coupled. The above code is "provably correct", but the proof does not lie in the type system; instead, it depends on the fact we only use that void* in a context that knows it is an int*.
In C++ you can use void* similarly. But you can also get fancy.
Suppose you want a pointer to anything printable. Something is printable if it can be << to a std::ostream.
struct printable {
void const* ptr = 0;
void(*print_f)(std::ostream&, void const*) = 0;
printable() {}
printable(printable&&)=default;
printable(printable const&)=default;
printable& operator=(printable&&)=default;
printable& operator=(printable const&)=default;
template<class T,std::size_t N>
printable( T(&t)[N] ):
ptr( t ),
print_f( []( std::ostream& os, void const* pt) {
T* ptr = (T*)pt;
for (std::size_t i = 0; i < N; ++i)
os << ptr[i];
})
{}
template<std::size_t N>
printable( char(&t)[N] ):
ptr( t ),
print_f( []( std::ostream& os, void const* pt) {
os << (char const*)pt;
})
{}
template<class T,
std::enable_if_t<!std::is_same<std::decay_t<T>, printable>{}, int> =0
>
printable( T&& t ):
ptr( std::addressof(t) ),
print_f( []( std::ostream& os, void const* pt) {
os << *(std::remove_reference_t<T>*)pt;
})
{}
friend
std::ostream& operator<<( std::ostream& os, printable self ) {
self.print_f( os, self.ptr );
return os;
}
explicit operator bool()const{ return print_f; }
};
what I just did is a technique called "type erasure" in C++ (vaguely similar to Java type erasure).
void send_to_log( printable p ) {
std::cerr << p;
}
Live example.
Here we created an ad-hoc "virtual" interface to the concept of printing on a type.
The type need not support any actual interface (no binary layout requirements), it just has to support a certain syntax.
We create our own virtual dispatch table system for an arbitrary type.
This is used in the C++ standard library. In c++11 there is std::function<Signature>, and in c++17 there is std::any.
std::any is void* that knows how to destroy and copy its contents, and if you know the type you can cast it back to the original type. You can also query it and ask it if it a specific type.
Mixing std::any with the above type-erasure techinque lets you create regular types (that behave like values, not references) with arbitrary duck-typed interfaces.
I'm still learning C++, and I'm doing some API work, but I'm, having trouble parsing this pointer arrangement.
void* data;
res = npt.receive(0x1007, params, 1, response, (void**)&data, size);
uint32_t* op = (uint32_t*)data;
uint32_t num = *op;
op++;
Can anyone explain what is going on with that void pointer? I see it being defined, it does something in the res line(maybe initialized?), then it's copied to an uint32 pointer, and dereferenced in num. Can anyone help me parse the (void**)&data declaration?
Pay attention when you use the void pointer:
The void type of pointer is a special type of pointer. In C++, void represents the absence of type. Therefore, void pointers are pointers that point to a value that has no type (and thus also an undetermined length and undetermined dereferencing properties).
This gives void pointers a great flexibility, by being able to point to any data type, from an integer value or a float to a string of characters. In exchange, they have a great limitation: the data pointed to by them cannot be directly dereferenced (which is logical, since we have no type to dereference to), and for that reason, any address in a void pointer needs to be transformed into some other pointer type that points to a concrete data type before being dereferenced.
From C++ reference
Firstly: What is npt?
Secondly: Guessing what npt could be some explanation:
// Declare a pointer to void named data
void* data;
// npt.receive takes as 5th parameter a pointer to pointer to void,
// which is why you provide the address of the void* using &data.
// The void ** appears to be unnecessary unless the data type of the
// param is not void **
// What is "npt"?
res = npt.receive(0x1007, params, 1, response, (void**)&data, size);
// ~.receive initialized data with contents.
// Now make the uint32_t data usable by casting void * to uint32_t*
uint32_t* op = (uint32_t*)data;
// Use the data by dereferencing it.
uint32_t num = *op;
// Pointer arithmetic: Move the pointer by sizeof(uint32_t).
// Did receive fill in an array?
op++;
Update
Signature of receive is:
<whatever return type> receive(uint16_t code, uint32_t* params, uint8_t nparam, Container& response, void** data, uint32_t& size)
So the data parameter is of type void** already so the explicit type cast to void** using (void**) is not necessary.
Considering the usage, the received data appears to be an array of uint32_t values IN THIS CASE!
Void as a type means no type and no type information regarding size and alignment is available, but is mandatory for lexical and syntactical consistency.
In conjunction with the *, it can be used as a pointer to data of unknown type and must be explicitly cast to another type (adds type information) before any use.
You usually have a void* or void** in an API, if you dont know the specific data type or only received plain byte data.
To understand this please read up C type erasure using void*
Please read up as basics before:
Dynamically allocated C arrays.
Pointers and Pointer Arithmetics.
From the code, ntp.receive tells you whether it receives anything successfully in the return code but it also needs to give you what it receives. It has a pointer that it wants to pass back, so you have to tell it where that pointer is so that it can fill it, hence (void **), a pointer to a pointer, being the address of your pointer, &data.
When you have received it, you know as the developer that what it points to is actually a uint_32 value so you copy the void pointer into one that points to a uint_32. In fact, this step is unnecessary since you could have cast the uint_32 pointer to void** in the above call but we'll let that slide.
Now that you have told the compiler that the pointer points to a 32 bit number, you can take the number on the other end of that pointer (*op) and store it in a local variable. Again, unnecessary, as *op could be used anywhere num is subsequently used.
Hope this helps.
I decided to create and use windows using a base class like this:
class Window
{
private:
static LRESULT WINAPI WindowProc(HWND _hWnd, UINT _uMsg, WPARAM _wParam, LPARAM _lParam);
protected:
virtual LRESULT onMessageNameGoesHere(/*parameters*/)
{
// Default handling
};
public:
// Other functions
};
So all windows are inherited from this class. This is WindowProc.
LRESULT WINAPI Window::WindowProc(HWND _hWnd, UINT _uMsg, WPARAM _wParam, LPARAM _lParam)
{
Window *window = (Window*)GetWindowLongPtr(_hWnd, GWLP_USERDATA);
switch (_uMsg)
{
case WM_SOMEMESSAGE:
return window->onMessageNameGoesHere();
case WM_NCCREATE:
SetWindowLongPtr(_hWnd, GWLP_USERDATA, LONG(LPCREATESTRUCT(_lParam)->lpCreateParams));
return true;
case WM_GETMINMAXINFO:
return window->onGetMinMaxInfo((LPMINMAXINFO)_lParam);
default:
return DefWindowProc(_hWnd, _uMsg, _wParam, _lParam);
}
}
WM_NCCREATE stores a pointer to the class associated to the window in GWLP_USERDATA. The problem is that WM_GETMINMAXINFO is received before WM_NCCREATE does, making it crash. (Yes, I know I need some code to avoid that)
So is there a way to set the minimum and maximum window size without WM_GETMINMAXINFO or maybe make that message be sent before WM_NCCREATE does?
Feel free to ask for more detail or for some more explanation.
I believe the answer is "no". This is one of the many places where the Windows OOP model has an impedance mismatch with that of C++.
The only solution I can think of is to use RAII to save/restore the context pointer in thread-local storage (make sure to save what was already there to avoid reentrancy isues) and to retrieve it as soon as your message handler is called. On Windows XP you can try __declspec(thread) or explicitly do this via TlsAlloc/TlsSetValue; on Windows Vista or later you might want to use FlsAlloc/FlsSetValue although I'm not sure if fibers can mess with things here...
I want more detailed information about cbClsExtra and cbWndExtra WNDCLASSEX members that are used in RegisterClassEx winapi.
MSDN says that this members can be used to set size of extra bytes that will be allocated for class and for each window instance accordingly.
MSDN says
The system initializes the bytes to zero.
1) Does this mean that bytes are initialized with zero value or system allocates zero (none) bytes by default?
2) The most important question is how to use this extra bytes (provide examples please with winapi used) and how they are used most common?
Thanks in advance.
Does this mean that bytes are initialized with zero value or system allocates zero (none) bytes by default?
initialization is always done on variables, so it means to sets the allocated extra memory to 0.
The most important question is how to use this extra bytes (provide
examples please with winapi used) and how they are used most common?
The only way to do this is via the GetClassLongPtr and GetWindowLongPtr functions, these functions are simple enough to not need examples (call Get* to get the value, and Set* set set the value, passing either the class ATOM or window HWND).
I guess this is a really old question and the person already went on with life, but I think it deserves a proper answer as I was struggling with it and the answer wasn't much help. Yes it stated how to set the extra memory and the ONLY functions to use; but much much more detail was NECESSARY.
You see, experience persons thinks things are obvious and common sense, but I beg to differ. Win32 API is not a very intuitive API. Once you learn it you get to understand certain patterns, but later discover that some parts of the API is very different from some. Example, Setting font for your window, is different from setting font in an Edit control; which is surprisingly very very different for Rich Edit Control.
Thus I always refer to MSDN documentation and when I cant get the information there; ask Stack Overflow.
///______MY SOLUTION _________
Here is how you use cbWndExtra, which is extra bytes you can allocate to each Window Instance of that class. I know not about cbClassExtra.
Note I use cbWndExtra as an alternative to GWL_USERDATA. With the latter I would create and new pointer to my special structure and set it to GWL_USERDATA. This struct has all state I need to manage the window object.
However I have been trying out cbWndExtra to avoid creating memory on the heap. For simple primitive variables.
Step 1. Create windowProc.def file. This contains enumerations and functions for accessing the window bytes in a type safe way.
#include <windows.h>
#define LINE_NUM_VIEW_WIDTH 0
#define CODE_EDITOR_EDITOR 0
#define CODE_EDITOR_LINE_VIEW (CODE_EDITOR_EDITOR + sizeof(HWND))
#define CODE_EDITOR_HEIGHT (CODE_EDITOR_LINE_VIEW + sizeof(HWND))
#define CODE_EDITOR_RESIZABLE (CODE_EDITOR_HEIGHT + sizeof(LONG))
#define LINE_NUMBER_VIEW_WND_EXTRA_BYTES sizeof(LONG)
#define CODE_EDITOR_WND_EXTRA_BYTES (CODE_EDITOR_RESIZABLE + sizeof(LONG))
#define getLineNumberViewWidth( hwnd) GetWindowLong(hwnd,LINE_NUM_VIEW_WIDTH)
#define setLineNumberViewWidth( hwnd, n) SetWindowLong(hwnd,LINE_NUM_VIEW_WIDTH,n)
#define getTextEditor( hwnd) ((HWND)GetWindowLongPtr(hwnd,CODE_EDITOR_EDITOR))
#define getLineNumberView( hwnd) ((HWND)GetWindowLongPtr(hwnd,CODE_EDITOR_LINE_VIEW))
#define setCodeEditorHeight(hwnd,n) SetWindowLong(hwnd,CODE_EDITOR_HEIGHT,n)
#define getCodeEditorHeight(hwnd) GetWindowLong(hwnd,CODE_EDITOR_HEIGHT)
#define isCodeEditorResizable(hwnd) GetWindowLong(hwnd,CODE_EDITOR_RESIZABLE)
#define setCodeEditorResizable(hwnd, yes) SetWindowLong(hwnd,CODE_EDITOR_RESIZABLE,yes)
Note the trick with GetWindowLong, GetWindowLongPtr. Use GetWindowLong for Long, int, bool, and the likes. Use GetWindowLongPtr for pointers. Also notice the Long in the name. the function returns sizeof(LONG) and stores sizeof(Long). And msdn states valid range is 0 to cbWndExtra - sizeof(Long). Thus even though you can allocate 1 byte of cbWndExtra, DONT! Allocate multiples of LONG. And also remember that GetWindowLongPtr stores and retrieves sizeof(LONG_PTR). valid range 0 - cbWndExtra - sizeof(LONG_PTR). LONG_PTR and LONG are different size on 64 bit windows.
It is really simple. GetWindowLong will always try retrieve Long. Thus if you allocate 12 bytes and try to retrieve index 10; that is a mistake as only 2 bytes can be retrieved. Maybe windows gives you a bly, but as far as I am concernes that is undefined behaviour. And I stay clear of undefined behaviour.
Note there is GetWindowWord as well. Never used it. There is no GetWindowByte, Short, Bool or any mechanism getting and setting 1 byte or 2 byte. Thus allocate one Long block for all your bools.
Step 2. create windowProc.cpp
#include <stdio.h>
#include "windowProc.def"
LRESULT CALLBACK windowProc(HWND hwnd,UINT msg,WPARAM wparam,LPARAM lparam)
{
switch(msg)
{
case WM_CREATE:
setCodeEditorHeight(hwnd,100); // from windowProc.def
printf("%i",getCodeEditorHeight(hwnd)); // from windowProc.def
return 0;
default: return DefWindowProc(hwnd, msg, wparam, lparam);
}
}
ATOM registerMainWindow()
{
WNDCLASSEX wincl = {0};
wincl.cbSize = sizeof(WNDCLASSEX);
wincl.hInstance = (HINSTANCE)0x400000;
wincl.lpszClassName = "JavWindowProc";
wincl.lpfnWndProc = windowProc;
wincl.hCursor = LoadCursor(NULL,IDC_IBEAM);
wincl.hbrBackground = (HBRUSH)(COLOR_BACKGROUND+1);
wincl.cbWndExtra = CODE_EDITOR_WND_EXTRA_BYTES; // Safely set the size with our enumeration from windowProc.def
return (LPCSTR)RegisterClassEx(&wincl);
}
HWND createMainWindow(const char *title,int width,int height)
{
static auto className = registerMainWindow();
return CreateWindowExA(
0, // Extended possibilites for variation
className,
title,
WS_CHILD,
0,0,width,height,
HWND_DESKTOP,
0,
(HINSTANCE)0x400000,
NULL // No Window Creation data// The alternative to cbWndExtra
);
}
Steps 3 Obviously create your main function with your message loop.
Hope this was a help to somebody.
I'm slightly puzzled by the lack of documentation on the issue, so I may be completely off track here:
When I allocate memory in order to return an object through an unique pointer whose value I have modified, what allocater should I use?
The documentation says that I can provide MIDL_user_allocate() and MIDL_user_free() and the stub will use these -- however that does not make sense in CLSCTX_INPROC_SERVER, as the calling object would need to use (and hence resolve) my allocater.
So, how should I allocate memory here, so that the stub code can properly free the list if the DLL is loaded into SVCHOST, and applications can still use the DLL directly if they so desire.
idl:
HRESULT GetItems([out] DWORD *count, [out, size_is(,count)] ITEM **items);
cpp:
HRESULT STDMETHODCALLTYPE impl::GetBuffer(DWORD *count, ITEM **items)
{
*count = 0;
*items = reinterpret_cast<ITEM *>(/* ??? */);
if(!*items)
return E_OUTOFMEMORY;
*count = 5;
/* fill in items */
return S_OK;
}
From here:
Out-parameters must be allocated by the one called; they are freed by the caller using the standard COM task memory allocator.
where COM task memory allocator is either the set of IMalloc methods or the set of CoTaskMemAlloc()/CoTaskMemRealloc()/CoTaskMemFree() functions that provide the same functionality.
The midl_user-*() functions you mention are used for RPC memory management. You need them in case you deal with RPC interfaces, not COM interfaces.