Re: Merits and uses of static vs. dynamic libraries
On Apr 13, 8:28 am, Paavo Helde <pa...@nospam.please.ee> wrote:
"Qu0ll" <Qu0llSixF...@gmail.com> kirjutas:
When should one create a static library as opposed to a
dynamic library and what are the relative merits of each
type?
I can see immediately that having one (perhaps large) static
library would be advantageous in the sense that you needn't
worry about keeping track of multiple dependencies so it
could be appropriate if you are developing a class library.
What are the other pros and cons?
Not really C++ specific, and shared libraries are not touched
by the current C++ standard, but anyway, here it goes...
Dynamic libraries are a later innovation,
They predate C++ by a large margin. (I believe Multix supported
dynamic linking, and other systems of that period certainly
did.)
the biggest selling point being the byte-saving both on disk
and in memory as shared libraries can be potentially shared by
many applications at the same time.
That was a major motivation for the early GUI systems (Sun OS,
etc.), where the GUI library often represented 90% of the size
of an executable. It's rarely relevant today.
It's especially irrelevant for libraries you (the average
programmer) write, which will only be used in a couple of
applications (which will typically require different versions of
the library anyway).
OTOH, it becomes much more difficult to keep track the
versions and ensure that each application uses the right
shared libraries, these problems are often regarded as "the
DLL hell" in the Windows world. To avoid this, each
application often uses its own set of semi-standard DLL-s
packaged together with the application, thus negating most of
any memory comsumption effect which it might have had.
To summarize, shared libraries should be used only in the
following situations IMO:
* standard implementation-provided libraries with fixed or
at least back-compatible binary interface, like kernel32.dll
or libm.so.
* implementing optionally loadable modules extending the
application functionality at run-time.
Windows won't pick up symbols in the root when linking a shared
library. (At least, that's my impression.) Which means that
any functionality which should be shared between the root and a
dynamically loaded object, or between different dynamically
loaded objects, must itself be in a DLL. (Maybe there are
options around this. And I think that's really what's behind
some of the examples you gave that I cut.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34