Re: Using legacy DLLs
A minor point of clarification is that if you derive an interface from
another interface (this is to add functionality, not reuse implementation,
e.g. the new interface requires more functinality to be provided by
the implementer), make sure all such interface derivations are single
parent only (no multiple derivation allowed for interfaces). You
can certainly use multiple derivation when implementing your interfaces
since those classes are never exported. Interface in this context is
a C++ class with only pure virtual methods and no data members
nor statics. Furthermore, be careful to never expose non-interface C++
classes as arguments in your interfaces. If you pass structs, make
sure these are C-conformant, e.g. with no code associated in methods,
constructors/destructors, overloaded operators etc (I'd use extern "C"
for structs passed as arguments).
Another limitation is you cannot use delete on the returned interface
pointers (Ben accounted for that in his example). You can follow
the COM lead here and have each interface provide a destruction
method that you'd call in place of delete. You can go an extra mile
and provide reference counting. Another extra mile would bring you
to dynamic interface interrogation (you can't use RTTI and dynamic
cast). The next mile would bundle all of those in a base interface
common for all of your interfaces. If you reached this far, I'd
suggest you simply use COM's IUnknown interface for your
base and GUIDs for interface identification, at which point you
can use most COM frameworks for your interfaces. You don't
need to make the last stretch and make everything COM-compliant
though - COM's threading models can be tricky and trip the
unaware... And you probably don't need the registration either.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================
"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
news:%23cXZKQ13HHA.1168@TK2MSFTNGP02.phx.gbl...
"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.