I just came across this article. If I'm reading it right, the author seems to suggest that one cannot export C++ classes (either in whole or in part) from a DLL (i.e. using the __declspec modifier). Instead, you should use a C style function to create an instance of the class and export that instead. However, a quick search of this forum reveals loads of posts which suggest the opposite. Who's right and who's wrong?
"A problem well stated is a problem half solved.” - Charles F. Kettering
You can not export a class, but you can export the methods and variables individually, you can also export these with C++ way of exporting. You have Visual C++ project types like MFC DLLs that export classes.
The mechanism of exporting a method with C style which returns an instance of given class is a very much tradditional way of doing it.
I just came across this article. If I'm reading it right, the author seems to suggest that one cannot export C++ classes (either in whole or in part) from a DLL (i.e. using the __declspec modifier). Instead, you should use a C style function to create an instance of the class and export that instead. However, a quick search of this forum reveals loads of posts which suggest the opposite. Who's right and who's wrong?
You read it wrong. This is the quote:
You can not directly export a C++ class from a dynamically loadable DLL.
The main point author makes is about plug-ins, i.e. a situation when dynamic dll loading [Edit: and explicit linkage!] is unconditionally implied.
Indeed, you just cannot explain your compiler that you intend to link your classes constructors/destructors/members later at runtime, somehow, maybe... That's why C-style export is mandatory for plug-ins. Besides, plug-ins are most of the times about cross-language usage, which is another reason for C-style export.
But in case you never need your dll to be loaded dynamically, you surely may export/import classes with no problem (well, problem might happen, but in this case it's gonna be very specific )
Last edited by Igor Vartanov; September 29th, 2010 at 09:29 AM.
Sorry Igor, you've confused me now. ALL dll's are dynamically loadable aren't they? Or are you referring to DLL functions loaded using LoadLibrary/GetProcAddress etc?
"A problem well stated is a problem half solved.” - Charles F. Kettering
Yes, and thank you for noticing that. Been talking about 'dynamic loading' I meant (and I believe, the author did as well) explicit linkage by means of GetProcAddress. Maybe that was the main point of your confusion from the very beginning.
With a standard 'C' source file, a .DEF file can be used to export functions if the program was originally written without __declspec modifiers. Can the same be done for C++ (i.e. class member) functions? I've never seen it done but it'd be interesting to know whether or not it's possible. At the very least, I assume that name mangling is going to make this tricky
"A problem well stated is a problem half solved.” - Charles F. Kettering
With a standard 'C' source file, a .DEF file can be used to export functions if the program was originally written without __declspec modifiers. Can the same be done for C++ (i.e. class member) functions? I've never seen it done but it'd be interesting to know whether or not it's possible. At the very least, I assume that name mangling is going to make this tricky
The DEF applies to functions only. With regard to classes, it's almost not worth exporting a class unless you [re]compile the dll each time you compile the app. The name mangling must match exactly and can change from compiler version to version.
With a standard 'C' source file, a .DEF file can be used to export functions if the program was originally written without __declspec modifiers. Can the same be done for C++ (i.e. class member) functions? I've never seen it done but it'd be interesting to know whether or not it's possible. At the very least, I assume that name mangling is going to make this tricky
Anyway, it's possible. Though not without certain limitations...
Last edited by Igor Vartanov; October 1st, 2010 at 03:10 PM.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.
Reply With Quote
Originally Posted by John E
That's why C-style export is mandatory for plug-ins. Besides, plug-ins are most of the times about cross-language usage, which is another reason for C-style export.
