Re: Using legacy DLLs

From:

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam>

Newsgroups:

microsoft.public.vc.language

Date:

Tue, 14 Aug 2007 10:04:10 -0500

Message-ID:

<uTdOsRo3HHA.3916@TK2MSFTNGP02.phx.gbl>

"Matt Osborn" <a@b.c> wrote in message
news:OUvVxdn3HHA.4476@TK2MSFTNGP06.phx.gbl...

You might as well throw away the baby and keep the bathwater. When
developing a multi-module application in C++, DLLs exporting common
classes and functions are the only way to go.

Not using "dllexport". Static libraries with C++ interfaces and DLLs with
COM interfaces will take you a lot farther.

If you are developing a library (as in 3rd party library), then you may
very well choose to sacrifice efficiency and portability for maintenance
reasons.

Using COM instead of dllexport doesn't sacrifice portability. COM is
supported by far more toolsets than __declspec(dllexport).

"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.