Re: Share .cpp and .h along projects
On Tue, 14 Aug 2007 13:36:14 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:
As for DLLs having "nothing to offer", consider:
1. As long as you are very careful, it is possible to fix bugs in
libraries
distributed as DLLs, tell people it's OK to replace the old a.dll with the
new one, e.g. by publishing it on your web site, or if you're MS, on
Windows Update, and fix every EXE and DLL that uses a.dll in the process.
2. They offer finer (at least easier) control of visibility than static
libraries.
3. While static data initialization suffers from the DllMain restrictions,
the order of it is deterministic WRT different modules ("modules" being
other DLLs and EXE). Not so for static libraries (though you can mitigate
it with #pragma, albeit less reliably). This is very useful when one
library uses another, and there are global mutexes and the like that have
to be initialized.
4. Linking to DLLs may be faster than linking to static libs.
5. VC++ doesn't look into DLLs when performing interprocedural
optimization, which can be very useful to suppress in some contexts. Off
the top of my head, it eliminates one objection to the DCLP, and it takes
compiler optimizations out of the picture for mutex locking/unlocking.
6. IMO, it would be nuts to statically link numerous large libraries into
a
program if there are other clients that could benefit from the size
reduction and points 1-5.
None of the above hold when using dllexport'ed classes, except possibly #3.
I have direct experience that (1), (3), and (5) hold for classes, and IMO
(6) is generally true. For (5), you have to be careful not to define any
inline functions or let the compiler define any default functions for you.
However, I presume that you mean global, not static data intialization.
Yeah, a good clue to that is what I later said about "global mutexes".
Initialization of function static variables is well-defined.
Ironically, it's the order of destruction of local statics that can be a
problem with DLLs. That's one of the things I was alluding to when I said
earlier, "... technical problems affecting the intersection of the C++
execution model with the Windows dynamic linking model, which VC++ still
needs to work on."
#5 at least is a sign of code with real bugs in it.
Oh, please. As I mentioned, being able to suppress interprocedural
optimization is a necessity for implementing mutex lock/unlock operations,
and it also eliminates one of the problems in the DCLP. By putting
WaitForSingleObject, ReleaseMutex, and others in opaque system DLLs,
correct compiler behavior for MT programming WRT these operations
essentially comes for free.
--
Doug Harrison
Visual C++ MVP