Re: Share .cpp and .h along projects
On Mon, 13 Aug 2007 16:03:13 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:
An updated DLL is expected to be a drag+drop replacement for the old
version.
If a program is distributed as a.exe/a.dll, I would never assume I could
use a later version of a.dll with an older version of a.exe without being
told explicitly that this is OK.
__declspec(dllexport) is going to break that all the time, in a way that a
COM-compatible interface (doesn't have to be COM-compliant with all the
extra registry stuff) won't.
You perceive that problem only because of your beliefs concerning DLL
substitutability. If you believed that __declspec(dllexport|dllimport) of
classes is equivalent to static linking WRT compilation dependencies, you
wouldn't think you could just overwrite a DLL with a newer version.
Instead, you'd understand you need to recompile all the DLL's clients.
If you have such close coupling, and are using DLLs for incremental loading
or some other purpose besides deployment, then make sure every update to the
DLL changes the filename so nobody confuses it for being compatible with the
previous version.
That's advisable for breaking changes when there are multiple clients that
cannot all be updated along with the DLL. (Example: The CRT and MFC DLLs.
Counter-example: DLLs developed for use by a program or group of programs
that are packaged as a whole.)
And deploying "reusable components" that way is a huge mistake, which seems
to be what it gets used for 99% of the time, causing the constant questions
in this group of "how can I use this library XYZ I bought from vendor ABC
two years ago with the new Visual Studio?"
I guess I've missed most of those questions. The ones I remember have to do
with CRT DLL mismatches and other genuine, technical problems affecting the
intersection of the C++ execution model with the Windows dynamic linking
model, which VC++ still needs to work on.
Generally, if something is so closely coupled that using a pure virtual
interface isn't good enough, you need C++ class definitions, then it needs
to be statically linked. Remember that giving the compiler access to the
class definition causes it to start inlining... what's the purpose of
putting the class in a separate DLL if the implementation is partially
inlined into the caller? You might as well put only half of the member
definitions in this DLL, a third in a second DLL, and a few in yet another
DLL.
Everything you said applies at least equally to static libraries, and since
I'm arguing that using __declspec(dllexport|dllimport) on classes must be
considered equivalent to static linking, a more interesting question would
be, "What are the advantages and disadvantages of using DLLs when static
linking is called for?"
--
Doug Harrison
Visual C++ MVP