DLL loosing "this" pointer
-
My "this" pointer in my DLL is getting f*ck up,.. I don't know why. I have create a small 72K zipped test application and dll that shows this problem. download it here. www.marino.dk/misc/dlltest01.zip run the application, and click on the 'help' menu and then the 'testme2' menu item. Here you should get an example of a "this" pointer being destroyed. Plz somebody help me, Peter Marino ( IO Interactive ) www.marino.dk
-
My "this" pointer in my DLL is getting f*ck up,.. I don't know why. I have create a small 72K zipped test application and dll that shows this problem. download it here. www.marino.dk/misc/dlltest01.zip run the application, and click on the 'help' menu and then the 'testme2' menu item. Here you should get an example of a "this" pointer being destroyed. Plz somebody help me, Peter Marino ( IO Interactive ) www.marino.dk
I don't understand what your objective is but I won't beat you about that. You are making a comparison of g_lpThis to an uninitialized this pointer in the CDeleteMeDLLApp::Start2 method. Your DLL is being loaded and initialized during the first call to LoadLibrary but this does not mean that you have an instance of the CDeleteMeDLLApp class on which you may make method calls. You are getting a raw pointer to the CDeleteMeDLLApp::Start2 method export and basically callin into very dangerous territory. Please explain more about what you are trying to do and I think we can all help you better. Cliff
-
I don't understand what your objective is but I won't beat you about that. You are making a comparison of g_lpThis to an uninitialized this pointer in the CDeleteMeDLLApp::Start2 method. Your DLL is being loaded and initialized during the first call to LoadLibrary but this does not mean that you have an instance of the CDeleteMeDLLApp class on which you may make method calls. You are getting a raw pointer to the CDeleteMeDLLApp::Start2 method export and basically callin into very dangerous territory. Please explain more about what you are trying to do and I think we can all help you better. Cliff
ok,... it sounds like I have completly misunderstood how the a dll should work. The Start2 test is comparing the g_lpThis pointer to the actual this pointer,... which isn't the same,.. why isn't it the same, that is my question. Ok, I got an answer at Codeguru,... it's because my Start2 is seen from the App as a "C" call and not a "C++" object call CDeleteMeDLLApp::Start2. This explains it. Which in turn also gives you the correct answer when you tell me that I don't have an instance of the CDeleteMeDllApp,.. well there is an instance, I just don't have it in my App program. thx a lot. now I can sleep :-) Peter Marino www.marino.dk
-
My "this" pointer in my DLL is getting f*ck up,.. I don't know why. I have create a small 72K zipped test application and dll that shows this problem. download it here. www.marino.dk/misc/dlltest01.zip run the application, and click on the 'help' menu and then the 'testme2' menu item. Here you should get an example of a "this" pointer being destroyed. Plz somebody help me, Peter Marino ( IO Interactive ) www.marino.dk
The "This" pointer in a member function of a class is actually an 'invisible' first parameter passed to the function by the compiler. For example, when you write the function : void CDeleteMeDLLApp::Start2( unsigned long dwDummy1, unsigned long dwDummy2 ) The compiler actually generates this as if it was : void CDeleteMeDLLApp::Start2(CDeleteMsDllApp* this, unsigned long dwDummy1, unsigned long dwDummy2 ) The problem here is that inside the DLL you are saying that "start2" is a class member function (and therefore has this 'invisible' first parameter called "this"). However, in the App you are telling the compiler it is a normal 'C/C++' function (and therfore it does not have a "this"). When the compiler generated the call to "Start2" is does not add the "this" bexcause it is not aware that "Start2" is a class member (and even if it was aware, the compiler does not now the address of the class instance 'theApp' at this point - only the DLL knows that. So the compilter cannot pass the address even if it knew it should) To correct this you must resolve this inconsistent view of the function - either make it a member in both places, or a non member in both places. You have 3 choices : (a) Use non-member functions in the dll, rather than class members; (b) Make the member functions 'static', so they do not have a 'this' pointer; (c) export the class from the DLL, rather than the individual member functions. When I do this, I often export a function that returns a pointer to the class, like this : In the Dll : CDeleteMeApp* declspec( dellexport) getClass() { return &theApp; } In the app : typedef CDeleteMeDll* (CALLBACK* GETCLASS)(); GETCLASS getClass; HLIB lib = LoadLibrary("deleteMeDll"); getClass = (GETCLASS)GetProcAddress("getClass"); CDeleteMeDLL* theClass = getClass(); theClass->Start(pWnd); theClass->Start2(1, 2); You need to rework you interface between the DLL and the App - either make it 'c-style', and export 'normal' functions (you can of course make these exported functions into 'wrapper' functions that simply call the appropriate class member function !), or make it 'C++ style', and export the class, not the member functions. Either way, the bottom line is to avoid exporting class member functions!! The root of this is that DLLs were invented before C++ was in widespread use, and therefore the DLL architecture has no knowledge of the concept of 'class' - DLLs were designed to hold code (functions) and data as separate elements, not classes (a hybrid mix