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.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================
"John A. Byerly" <johnbREMOVE@flashcutcnc.REMOVEcom> wrote in message
news:xq_vi.4590$ZW4.2869@trndny04...
"Alexander Nickolov" <agnickolov@mvps.org> wrote in message
news:OqBHoe52HHA.4184@TK2MSFTNGP06.phx.gbl...
Your problem is that the DLL exports C++ classes. You
can either convert your project to use the same compiler
(VC6), or create a wrapper COM-based (or C API
based) DLL and build that with VC6. Both C APIs and
COM APIs allow a DLL to be used regrdless of the
compiler used by the hosting application. Note both for
COM and C API you must translate your arguments so
that no C++ classes are passed outside of the DLL.
Are you saying that VC++ 2005 doesn't allow C++ classes to be exported?
Or that it does it differently? The reason I ask is that the mechanism
we use to extend one or our products (written in VC++ 6.0) is through
DLLs. If a DLL is detected, we load it and present the additional
features to the user. I am hoping that when we eventually upgrade to
VC++ 2005 (or 2008), we won't have to redesign these interfaces.
Thanks!
JAB