Re: cloning at the interface level?
On Aug 5, 8:18 am, Paavo Helde <nob...@ebi.ee> wrote:
James Kanze <james.ka...@gmail.com> kirjutas:
On Aug 1, 1:12 am, Erik Wikstr=F6m <Erik-wikst...@telia.com> wrote:
[...]
might however be able to create a third, shared heap in which
both DLLs may allocate and deallocate.
According to the collegues here who develope under Windows,
there's a simple way to make malloc (and thus new) use a shared
heap, at link time. (I think it involves linking against a C
runtime which puts malloc/free in a shared library, but I'm not
too sure.)
Yes, it's quite easy to do (use DLL version of runtime
library, this is default in later MSVC versions), however,
this is quite fragile. One can really do this only if one has
source code of all libraries and can recompile everything to
use different version of runtime library when needed (for
Debug build, or when upgrading to the next compiler version,
for example).
If there is a library which is distributed as a binary DLL,
then the simple approach cannot work in principle (unless the
vendor provides a DLL for each combination of compiler and
runtime library in existance, which is not so simple any more
;-). So if the library allocates any dynamic objects by new
and hands them out to the client, it has to ensure that the
client would be able to delete them properly. The library can
use per-class operator new/operator delete to achive this
transparently.
Obviously, if the library furnisher goes out of their way to
make life difficult for you, then life will be more difficult.
My response to that would be to only use libraries developed by
competent teams. (But I know, you don't always have a choice.)
For exposing STL objects from such a library one might think
about using custom allocators, but this will not work anyway
as the client code might use a different STL implementation.
So basically a binary DLL library should not use any STL in
its interface (like std::string, which is really pity).
Excuse me, but the STL is part of the compiler, so there can
only be one. What can make a difference (and not just with the
STL) is compiler options; that's a problem pretty much
everywhere. Some compiler options affect binary compatibility,
and you have to use the same ones in every component you expect
to link together. There is, regretfully, no realy good solution
for this.
--
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