Re: Share .cpp and .h along projects

On Tue, 14 Aug 2007 13:17:48 +0300, Alex Blekhman <tkfx.REMOVE@xxxxxxxxx>
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.

--
Doug Harrison
Visual C++ MVP
.

Relevant Pages

  • Re: Share .cpp and .h along projects
    ... You may not care about memory/disk/download time/execution time savings, ... As for DLLs having "nothing to offer", ... libraries. ... Initialization of function static variables is well-defined. ...
    (microsoft.public.vc.language)
  • Re: EncryptMessage Memory leak
    ... You are correct about the dlls, ... I should say in any case that these two libraries are the main difference ... Yet memory continues to be leaked in the EncryptMessage call (I've proved ... these two dlls then I could see how you'd leak memory. ...
    (microsoft.public.platformsdk.security)
  • Re: Linux, X, ld, gcc, linking, shared libraries and stuff
    ... all the dependent DLLs (and all their dependent DLLs and all their ... DLL, though, this triggers the OS to actual load and link that DLL...hence, ... if your libraries are accessed almost immediately and ... As noted, though, most OSes out there are anything but "toolmaker's view" ...
    (alt.lang.asm)
  • Re: WM_TIMER crash (maybe)?
    ... addition, I suspect that, given the debug dialog IS, in fact, a dialog, and therefore it ... For example, if you install VC, it typically installs the ... that you could be replacing older DLLs with the latest redistributable DLLs. ... the rest were system DLLs, including OLE/COM libraries ...
    (microsoft.public.vc.mfc)
  • Re: COBOLs Influence on C
    ... paths get fixed by changing to dlls. ... objects) are dynamic load libraries. ... It fails the job hours before the program runs, thereby allowing the error to be fixed. ... Who changes the library load paths? ...
    (comp.lang.cobol)
Loading