Re: Using legacy DLLs
"John A. Byerly" <johnbREMOVE@flashcutcnc.REMOVEcom> wrote in message
news:d%Ewi.1292$Be.948@trndny04...
"Alexander Nickolov" <agnickolov@mvps.org> wrote in message
news:%23xLzN9d3HHA.464@TK2MSFTNGP02.phx.gbl...
Rule of thumb - never export C++ classes from a DLL in any
shape or form (including as functions/method arguments). The
bad news is - yes - you will have to redesign your interfaces.
Your problem is not thinking of source vs binary interface
implications. By exposing source-level interfaces from binary
units (DLLs) you introduce source-level dependency. It's as
tightly coupled as if everything was compiled in a single executable
in the sense you muct use the same compiler for all the modules.
In short - there's no binary compatibility between the different
binary units (DLLs). This is a deployment level problem.
I find this really unfortunate. I (very painstakingly) designed
interfaces for our application that would allow it to be expanded in the
future simply by adding appropriately written DLLs. One interface was for
an interpreter (in case we need to support other programming languages),
another for our hardware interface (in case we needed to support different
hardware), and still another for communications (RS-232, parallel, USB,
etc.). We also made a distinct separation between our background
processing and our UI so that one UI could be replaced for another. This
interface allows the UI to make calls via a C++ API, and receive and
respond to messages from the back end.
According to Microsoft, the way to make these interfaces visible was to
export them with __declspec(dllexport), which is what I did. As for
Hmm, you got bad information there. The better way is with v-tables.
If you have good separation, it shouldn't be too hard to define a pure
virtual interface as a base class, and consume that interface class.
Virtuals calls have a small, but non-zero, cost, so if your interfaces are
really chatty you might eventually want to convert to batch/bulk operations.
Just change your public header files to:
class ICommClass
{
public:
virtual void OpenPort( whatever params ) = 0;
// other member functions
};
extern "C" __declspec(dllimport) ICommClass* CreateCommClass( constructor
args );
extern "C" __declspec(dllexport) void DestroyCommClass( ICommClass* );
and move the actual data members to the implementation files (or
project-local headers):
class CommClass : public ICommClass
{
// some data members here
public:
virtual void OpenPort( whatever );
};
extern "C" __declspec(dllexport) ICommClass* CreateCommClass( constructor
args )
{
return new CommClass( args );
}
extern "C" __declspec(dllexport) void DestroyCommClass( ICommClass*
pInstance )
{
delete static_cast<CommClass*>(pInstance);
}
Now your clients will use the CreateXYZ and DestroyXYZ functions, so that
all allocations of XYZ are done from a single heap, and then call methods
normally on the returned pointer. Note that global functions are dllexport,
but class definitions (including the interface) are not.
You ought to be able to do this conversion slowly using your original
compiler version. After you refactor one DLL for v-tables, you can then try
compiling it using the new compiler, and everything should continue working.
Note that if you have been passing MFC objects across module boundaries then
you'll still be in trouble. But from your description of your project you
have GUI concerns isolated away from your interface DLLs, so you should be
ok. Don't try passing STL objects like std::string between DLLs, either.
Pass a character pointer (and possibly length) instead, and make a new
CString or std::string in the receiving module if needed.