Re: creating a c++ dll

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Arnaud Debaene (adebaene_at_club-internet.fr)
Date: 03/23/04


Date: Tue, 23 Mar 2004 19:25:16 +0100

Doug Harrison [MVP] wrote:
> Arnaud Debaene wrote:
>
>> Sure. I was referring to the many apps that are splitted among
>> several private DLLs which are used only by this app. I don't see
>> the usefullness of such a design.
>
> Possible benefits include:
>
> Faster linking.
Right.

> Reuse by other related apps and DLLs, perhaps ones distributed in
> different packages or used internally by the organization that wrote
> them.
Why not, but if the DLL has been designed for the app, it often is too
specialized for reuse.

> Finer control of names visible to other entities which link to them.
namespaces and PIMPL idiom are better alternatives.

> Ability (albeit limited and imperfect) to control order of
> initialization of static duration objects (globals and class statics)
> such as mutexes in the sense that a DLL X that implicitly links to
> DLL Y can be assured Y's globals are initialized before X's. This
> would not be the case if X and Y were static libraries.
Hum... I wouldn't rely on this in production code, that's too unmaintenable
and implicit...

>> but I feel DLLs are often misused in other cases when they make the
>> programmer life more complicated (CRT versions' mismatch ...)
>> without any real benefit.
>
> If you view C++ DLLs which tightly integrate with other modules as
> equivalent to static libraries WRT compiler and CRT versioning
> issues, then those concerns go away.

WRT ?????

Don't forget the overhead (ableit minimal) of cross-modules calls. There may
also be a concern with app startup time (if using static libraries, you win
at startup time what you've loose at link time).

Arnaud
MVP - VC



Relevant Pages

  • Re: AfxBeginThread crash
    ... library, it compiles fine, but when afxbeginthread is called, the app ... A frequent problem with using the static libraries is that if you call a DLL it has its own independent library, so reallocating something passed between app and DLL won't work. ...
    (microsoft.public.vc.mfc)
  • Unresolved symbols when deriving in dll
    ... I'm adding to this dll all those static libraries. ... Now I'm trying to add this created dll to my main app. ... linker says there are undefined references. ...
    (microsoft.public.vc.language)
  • Re: Unresolved symbols when deriving in dll
    ... I'm adding to this dll all those static libraries. ... I'm defining some names to correctly set ... > my app I'm creating my class. ...
    (microsoft.public.vc.language)
  • Re: Firefox and Sound
    ... number of loads that app performed. ... only references to entry points in the dll. ... specified entry points in it can't be found, ... but the download manager said it was only 78.8 MB. ...
    (comp.os.os2.apps)
  • Re: New Delphi roadmap is coming: NO UNICODE PLEASE!
    ... Avoids DLL hell, because it ... The app is deployed and the user is getting an error. ... instances where upgrading .NET broke things that were working. ... Coming from Delphi, this isn't any big deal of course. ...
    (borland.public.delphi.non-technical)