In the exemple code, the c++ code for the class A to export is compiled with the main program so there is no problem during the lonking.
But what we want is to have DLLs that work as blackboxes which means that the c code (not the header) is unknown to the main program. This would be the common scenario for plug-ins. you have only access to the header file (here "ExpClass.h").
If we change the project exemple moving the "ImplA.cpp" code to one (or the two dll), then there is a link problem because the main program does not find the object any longer.
If we include the ".lib" file corresponding to the dll in the folder of the application that contains all the object files, it links...but we need the lib file during the comilation of the application...so it is not like a plugin where we just have the dll.
So how can we successfully link when the main program does not have access to either the .cpp, the .obj or .lib files of the class to import/export?
Thanks very much for so a good article. It really solve a serious issue I got.
I'm implementing a Web Service in .NET and needed to use some class library written in C++ Builder. The problem was how to use those classes in C#. Well, I write a C++ class importing the classes from C++ Builder using the guidelines in this article. Then, write a classes in Managed C++.NET to wrap those and finally connecting to the C# World. One more time, thanks.
I am new to dll programming so bare with me.
Windows appears to treat dlls as shared memory spaces so that multiple programs can access the same dll. This design prohibits me from allocating memory in the main program and deallocating it in the dll, visa versa. I am developing a plugin system however so that one dll is only used by one program once. The design also calls for memory allocations to ocur across the two separate heaps. Is there anyway i can load a dll in this fashion? I understand there are globalallocs functions, is this my only way? What are the consequences of using these functions?
Heres my problem:
The main propgram calls into a dll via a virtual function.
The dll contains an instance of the class that is derievied from some base class that the main program is aware of allowing me to do the former. this works great.
The propblem areas if the dll class calls any function from the main program that has STL add a new entry into an STL::MAP. In the pseudo-code below, when the DLL calls AddObject() an access violation occurs when STL adds the CObject pointer
/// Main Program /////////////////////////
virtual DoIt(CManager *man);