Re: Need to create a C lib - using C++ classes - is it possible
On May 27, 7:48 pm, Paavo Helde <nob...@ebi.ee> wrote:
James Kanze <james.ka...@gmail.com> kirjutas:
[...]
To get this a bit more on-topic, I compare the Windows model
with Linux dynamic loader. There are both pros and cons:
[...]
Cons:
One cannot have dependency cycles among dynamically loaded
modules
.
Actually I think this is rather a "pro".
Yes and no. But if I understand your explination correctly, you
can in fact have cycles under Windows as well, if the modules
are explicitly loaded (e.g. as plugins), and that's probably the
only time you'd want them. (The root used, and thus depends on,
various plugins, and the plugins use common functionality in the
root.)
No, I probably expressed myself badly. The plugins are
compiled and linked after the root executable is ready. The
root executable does not know anything about the plugins by
itself. When started, it reads the names of needed plugin
files from registry or somewhere else, and loads them
explicitly with LoadLibrary() Windows SDK call. The plugins
depend on the .EXE module - this is already loaded into
memory, so everybody is happy.
The root module must know something about the plugins: an entry
point, for example. I think what you meant was that it only
knows it "symbolically", as a string constant in the code, and
not as some information in the .exe or the .dll format which the
system must exploint.
[...]
Any dynamic linking introduces any number of additional
problems with regards to version management, binary
compatibility, etc., and it's better to avoid it except
where the advantages outweigh these costs. Basically, about
the only implicit dynamic linking which I'd use is that of
the system ABI (to ensure portability to different versions
of the system) and low level libraries which can be more or
less assimilated to the system (data base interface, etc.).
Under Unix (my usual platform), I don't think I've ever
invoked dlopen except with RTLD_LOCAL, and except for the
bundled system libraries and Sybase, I don't use any
implicit dynamic linking. Under Windows, I rather suspect
that I'd do likewise---including dynamic linking for the
system API and low level functions like malloc. (But I'm
not sure: it partially depends on what is bundled with the
OS, since you don't want to have to deliver additional
system level DLL's with your application.)
Yes, there are lots of problems with dynamic linking. However,
they provide a better modularity for the whole system, and at
least on Windows, they provide a quite good additional layer
of encapsulation.
The additional modularity and encapsulation is useful in some
cases: plugins, and versionning for system level ABI's come to
mind. When those advantages outweigh the cost (or the cost is
minimal, e.g. when the dynamic object you link is bundled with
the OS, or must be provided separately anyway because of
licensing issues), then fine. But they create serious problems
with regards to deployment and versioning.
--
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