On Tue, 14 Aug 2007 13:17:48 +0300, Alex Blekhman <tkfx.REMOVE@yahoo.com>
wrote:
Actually, Ben has a point here. DLL's have long been boasted
of their substitutability and "after-market support", as
MSDN puts it. Without these advantages over static libs (who
cares about memory or disk savings anymore) DLL's have
nothing to offer.
Like I said, "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." I can't help it if some
think differently. They're simply wrong. When I hear stuff like this, it
helps me understand why MS locked Vista down in all the ways it did, but
then I can't fathom why anyone would replace one DLL with another on their
own initiative and expect everything to be fine without the developer of
the DLL telling them it's OK. I personally can remember doing this with
two
versions of RICHED32.DLL, but that was just an experiment to help me
clarify a bug in one or the other so I could report it to MS. I never
expected it to be a viable solution to any problem I was having.
You may not care about memory/disk/download time/execution time savings,
and that's your right, but I hope you respect the fact that others may
still care about these things.
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.
However, I presume that you mean global, not static data intialization.
#5 at least is a sign of code with real bugs in it.