Interesting Question on DLL...use class* as a parameter../??
-
HI, I want to pass class* as a parameter to DLL.. Without using MFC extension dll... I mean as a regular dll.. I think when I correctly pass the address information of Class*, I could call the method of it.. Is it difficult to understand?? See Next codes: In exe : 1. declare Class CA (no inheritance..) 2. define all the methods of Class CA.. 3. in some handler code, CA* inexe = NULL; Set(inexe); inexe->aa(); inexe->bb(); In Dll : 1. declare and define export func Set() as follows: void Set(CA* indll) { CA SI; //SI is instance of CA in DLL indll = &SI; } 2. then I can copy the address of CA instance in DLL..Right? so now inexe has address of CA instance in DLL.. Is it correct?? One more thing that makes life horrible.. I'll declare and define of CA in exe that has different implementation of CA's methods... I mean, in dll aa() returns 10 but in exe aa() return 20... Then I'll call methods of CA in dll... But in reallity it won't work... In exe, when I call the Set() with appropriate CA*, the result of inexe()-> returns 20 not 10...why?? I think when using the address, I could access the CA implementation in DLL.. But It just wouldn't work.. If anybody has a interest in this send me a mail... Then I'll send you immedialtely complete sample DSW... and other DSP and cpp..h...lib...exe....dll...OK?? So thanks for reading .... :-) Regardz -Ryan
-
HI, I want to pass class* as a parameter to DLL.. Without using MFC extension dll... I mean as a regular dll.. I think when I correctly pass the address information of Class*, I could call the method of it.. Is it difficult to understand?? See Next codes: In exe : 1. declare Class CA (no inheritance..) 2. define all the methods of Class CA.. 3. in some handler code, CA* inexe = NULL; Set(inexe); inexe->aa(); inexe->bb(); In Dll : 1. declare and define export func Set() as follows: void Set(CA* indll) { CA SI; //SI is instance of CA in DLL indll = &SI; } 2. then I can copy the address of CA instance in DLL..Right? so now inexe has address of CA instance in DLL.. Is it correct?? One more thing that makes life horrible.. I'll declare and define of CA in exe that has different implementation of CA's methods... I mean, in dll aa() returns 10 but in exe aa() return 20... Then I'll call methods of CA in dll... But in reallity it won't work... In exe, when I call the Set() with appropriate CA*, the result of inexe()-> returns 20 not 10...why?? I think when using the address, I could access the CA implementation in DLL.. But It just wouldn't work.. If anybody has a interest in this send me a mail... Then I'll send you immedialtely complete sample DSW... and other DSP and cpp..h...lib...exe....dll...OK?? So thanks for reading .... :-) Regardz -Ryan
There are a few things that you'd need to change to make it work the way that you intended it to work. First of all, you need to change the Set function to take in a pointer to a pointer. Secondly, in your set function you are creating a CA object on the stack (which will get destroyed as soon as the function returns, even though you may have copied the correct address - which doesn't happen anyway. Try this... In DLL: Set(CA** ppCAInDll) { CA * pA = new CA; *ppCAInDll = pA; } In EXE: CA* inexe = NULL; Set(&inexe); inexe->aa(); inexe->bb(); Make sure you delete the object pointed to by inexe, since it's been new'ed in the dll.
-
HI, I want to pass class* as a parameter to DLL.. Without using MFC extension dll... I mean as a regular dll.. I think when I correctly pass the address information of Class*, I could call the method of it.. Is it difficult to understand?? See Next codes: In exe : 1. declare Class CA (no inheritance..) 2. define all the methods of Class CA.. 3. in some handler code, CA* inexe = NULL; Set(inexe); inexe->aa(); inexe->bb(); In Dll : 1. declare and define export func Set() as follows: void Set(CA* indll) { CA SI; //SI is instance of CA in DLL indll = &SI; } 2. then I can copy the address of CA instance in DLL..Right? so now inexe has address of CA instance in DLL.. Is it correct?? One more thing that makes life horrible.. I'll declare and define of CA in exe that has different implementation of CA's methods... I mean, in dll aa() returns 10 but in exe aa() return 20... Then I'll call methods of CA in dll... But in reallity it won't work... In exe, when I call the Set() with appropriate CA*, the result of inexe()-> returns 20 not 10...why?? I think when using the address, I could access the CA implementation in DLL.. But It just wouldn't work.. If anybody has a interest in this send me a mail... Then I'll send you immedialtely complete sample DSW... and other DSP and cpp..h...lib...exe....dll...OK?? So thanks for reading .... :-) Regardz -Ryan
I think that there is a fundamental concept that must be understood. A regular dll (a dll that is not a MFC extension dll) can be called by programs compiled by any compiler capable of calling DLLs. That is, your dll is compatible with Visual Basic and many other development facilities. Most of them do not know what a C++ class is, so it is unlikely (impossible?) for you to be able to have a class as a parameter. I that a couple of possibilities are: (1) make an MFC extension dll that can be called by your MFC programs and a second dll that is a regular dll that calls the first dll and that can be called by non-MFC programs (2) create an (ActiveX) Automation interface, which (I think) can be implemented as either a dll or an exe. A third possibility might be that you write an MFC extension dll and a separate exe that provides an Automation interface and that calls the extension dll.
-
There are a few things that you'd need to change to make it work the way that you intended it to work. First of all, you need to change the Set function to take in a pointer to a pointer. Secondly, in your set function you are creating a CA object on the stack (which will get destroyed as soon as the function returns, even though you may have copied the correct address - which doesn't happen anyway. Try this... In DLL: Set(CA** ppCAInDll) { CA * pA = new CA; *ppCAInDll = pA; } In EXE: CA* inexe = NULL; Set(&inexe); inexe->aa(); inexe->bb(); Make sure you delete the object pointed to by inexe, since it's been new'ed in the dll.
Hi, really thanks for your response....:-) Unfortunately, it just wouldn't work.. I think the same idea like you...I have to pass the address of class's intance...I mean I should pass the address of pointer to class's instance in DLL.. Anyway, the result of aa() is that of the implementation in exe..not in DLL.. As far as I know about the class memory allocation modeling, the pointer of class should point the instance's top.. In this case, (no member variable, 4 member functions) it should point the constructor(first method)'s address.. So I think that if I could point out the proper address of class, I can point the proper binary implementation... But, as a result....I was wrong.. I want to find this out what the hell is going on in dll.. And about the class memory allocation... If you have some interest about this..Let's dig it out!! Give me your e-mail...I'll send you the whole codes I have.. If not...Thank you very much for suggestion.. And later I'll let you know the result of my study.. Regardz -Ryan -p.s The former responser's idea is wonderful.. I theaded also his idea.. Checking it out will be helpful too...
-
I think that there is a fundamental concept that must be understood. A regular dll (a dll that is not a MFC extension dll) can be called by programs compiled by any compiler capable of calling DLLs. That is, your dll is compatible with Visual Basic and many other development facilities. Most of them do not know what a C++ class is, so it is unlikely (impossible?) for you to be able to have a class as a parameter. I that a couple of possibilities are: (1) make an MFC extension dll that can be called by your MFC programs and a second dll that is a regular dll that calls the first dll and that can be called by non-MFC programs (2) create an (ActiveX) Automation interface, which (I think) can be implemented as either a dll or an exe. A third possibility might be that you write an MFC extension dll and a separate exe that provides an Automation interface and that calls the extension dll.
Hi, Thanks for your response.. A regular dll..and not MFC extension dll.. As I found a minute ago in MSDN, the regular dll has 3 types.. 1. Non-MFC DLLs 2. Regular DLLs statically linked to MFC 3. Regular DLLs dynamically linked to MFC I used #3 type...And what you point out is #1 type.. Hm.... Well, you are right in your point..Sorry for I didn't state the exact information about situation... In #3 type, I can use classes in DLL and can not export the class and all other members of it..Am I correct?? But I can't convince that I can export class* as a parameter Anyone know about this....?? And about your suggestion on possibilities: (1)DLL in DLL... I wonder if an exe can't access the dll's exports, neither it is with regular dll... And I have no compile error and link error with #3 type, I would not think about this... (2) Use Automation Interface.... Using COM...well I think I could make this dll as COM server But what is with the Automation??..Need your teaching... And my target is polymorphism of method's implementaion.. I'll separate implementation of class's method in exe and in dll so that I can use proper method of it... I know this is not the purpose of dll and c++.. If I need polymorpism, I can use virtual keyword.. But this is not good for reuse, as you can read in Essentil COM #1, for the real reuse of codes.. The source level reuse of legacy code is not effective.. And I'm tired to work on registrys....Huh... So for simple functionality I'll use this way rather than COM and ATL.. This is some copycat of COM..:-) Until the unveil of C# and .NET, I don't want to implement COM server..I'll just use components the others have done.. In .NET and CLR, COM is just a file...no registry needs.. Huh... Anyway thanks for your response... Regardz -Ryan -p.s Read the other thead of my question.. Mr. Jignesh made a good response...Check it out..
-
HI, I want to pass class* as a parameter to DLL.. Without using MFC extension dll... I mean as a regular dll.. I think when I correctly pass the address information of Class*, I could call the method of it.. Is it difficult to understand?? See Next codes: In exe : 1. declare Class CA (no inheritance..) 2. define all the methods of Class CA.. 3. in some handler code, CA* inexe = NULL; Set(inexe); inexe->aa(); inexe->bb(); In Dll : 1. declare and define export func Set() as follows: void Set(CA* indll) { CA SI; //SI is instance of CA in DLL indll = &SI; } 2. then I can copy the address of CA instance in DLL..Right? so now inexe has address of CA instance in DLL.. Is it correct?? One more thing that makes life horrible.. I'll declare and define of CA in exe that has different implementation of CA's methods... I mean, in dll aa() returns 10 but in exe aa() return 20... Then I'll call methods of CA in dll... But in reallity it won't work... In exe, when I call the Set() with appropriate CA*, the result of inexe()-> returns 20 not 10...why?? I think when using the address, I could access the CA implementation in DLL.. But It just wouldn't work.. If anybody has a interest in this send me a mail... Then I'll send you immedialtely complete sample DSW... and other DSP and cpp..h...lib...exe....dll...OK?? So thanks for reading .... :-) Regardz -Ryan
Hi Ryan, I think you get 20 because, when you compile the exe, the compiler knows its implementation of CA, so it calls its functions. The compiler has no mean to distinguish between a CA object created in your exe and one created in the dll. An object contains only data members and virtual tables, the member functions are just like any other global function, but they are passed
thisas the first parameter: this is how they can actually access object's data. When you use a CA object constructed in the dll, you get its binary data but not its member functions. And I think you may have unpredictable run-time errors if their internal data format is not the same. I don't know how you can solve this :) Cheers, Paolo -
Hi Ryan, I think you get 20 because, when you compile the exe, the compiler knows its implementation of CA, so it calls its functions. The compiler has no mean to distinguish between a CA object created in your exe and one created in the dll. An object contains only data members and virtual tables, the member functions are just like any other global function, but they are passed
thisas the first parameter: this is how they can actually access object's data. When you use a CA object constructed in the dll, you get its binary data but not its member functions. And I think you may have unpredictable run-time errors if their internal data format is not the same. I don't know how you can solve this :) Cheers, Paoloa) If you want two implementations of the same interface, you need to use virtual functions. Make a base class that has your interface, and then derive two classes from it - one that returns 10, and one that returns 20. Then objects of your class will have a virtual method table (pointer at the beginning of the object's data) that points to a list of function pointers, that's how you can get a different function to be called. The first responder had the right idea RE: returning a pointer to a pointer. b) Just make sure that the EXE and the DLL both include the header file that defines the interface, and they will work with each other. c) DLLs can be C++ specific, they don't -have- to be compatibile with Visual Basic or any other language.
-
There are a few things that you'd need to change to make it work the way that you intended it to work. First of all, you need to change the Set function to take in a pointer to a pointer. Secondly, in your set function you are creating a CA object on the stack (which will get destroyed as soon as the function returns, even though you may have copied the correct address - which doesn't happen anyway. Try this... In DLL: Set(CA** ppCAInDll) { CA * pA = new CA; *ppCAInDll = pA; } In EXE: CA* inexe = NULL; Set(&inexe); inexe->aa(); inexe->bb(); Make sure you delete the object pointed to by inexe, since it's been new'ed in the dll.
I don't really have a lot of experience in this field, but I think using a second set of dll's for the different classes (one for each class you want to use) should do the job (passing the current class-dll-name to your dll, which dynamically loads it). Exporting classes form dll's is documented in some postings on codeguru and codeproject). Wolfgang
-
a) If you want two implementations of the same interface, you need to use virtual functions. Make a base class that has your interface, and then derive two classes from it - one that returns 10, and one that returns 20. Then objects of your class will have a virtual method table (pointer at the beginning of the object's data) that points to a list of function pointers, that's how you can get a different function to be called. The first responder had the right idea RE: returning a pointer to a pointer. b) Just make sure that the EXE and the DLL both include the header file that defines the interface, and they will work with each other. c) DLLs can be C++ specific, they don't -have- to be compatibile with Visual Basic or any other language.
For MFC programmers, an important distinction is whether a DLL is an MFC Extension DLL or not. It is certainly true that a regular DLL can be C++ specific to the extent of being incompatible with other languages such as Visual Basic, but what is important is that MFC classes can be shared between EXEs and DLLs only when the DLL is an MFC Extension DLL. See MFC "TN011: Using MFC as Part of a DLL" and "TN033: DLL Version of MFC".