Re: Share .cpp and .h along projects

On Mon, 13 Aug 2007 16:03:13 -0500, "Ben Voigt [C++ MVP]"
<rbv@xxxxxxxxxxxxx> 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
.

Relevant Pages

  • Re: mfc size
    ... your DLL size but not solve any problems; and you cannot use such a DLL with any MFC ... MFC environment, so a DLL that does static linking will royally and totally fail (the app, ... for example, will not be able to find the window map for the windows created in the DLL, ...
    (microsoft.public.vc.mfc)
  • Re: Problem with reading an int with operator>>
    ... implemented in header files, is compiled into MSVCP60.DLL. ... Because it makes it impossible to patch std::string without rebuilding MSVCP60.DLL (if you use static linking). ... At the time the decision was made to include string in the DLL, it obviously wasn't known that it either had any bugs in or that there would be a problem with patching the DLL in an SP, which is obviously the normal way that library bugs are handled. ... I believe this allows MS to fix the CRT DLLs using Windows Update ...
    (microsoft.public.vc.stl)
  • Re: VC C++ 2005 sp1 "vcredist_x86.exe"
    ... It appears I now have to execute a package ... linking the run-time to the DLL linking? ... I don't believe we were doing static linking with the MSVC6 version, ... The manifest itself appears to contain direction mention of the VC8 DLL ...
    (microsoft.public.vc.language)
  • Re: VC++ 5 Q. - Shared DLL vs. statically linked lib?
    ... I decided to try statically linking MFC and to my surprise it only added around 150K to the program size. ... I'm not sure how much shared memory is created at run time, but I'm pretty convinced that static linking doesn't add that much overhead and it got rid of the need for a bunch of DLLs. ... I'm not running multiple apps - just the one standalone app. ... Unless you are running multiple applications that would use the DLL I don't think it would make much difference and you might want your application to be more standalone anyway just in case the world changes and your program continues to use the old paradigm. ...
    (microsoft.public.vc.mfc)
  • Re: VC C++ 2005 sp1 "vcredist_x86.exe"
    ... no longer run on distributed-to machines. ... It appears I now have to execute a package ... linking the run-time to the DLL linking? ... I don't believe we were doing static linking with the MSVC6 version, ...
    (microsoft.public.vc.language)
Loading