Re: STL objects and binary compatibility
osama178@gmail.com wrote in
news:740ee874-4c83-42a5-8bcd-5dad161e1f38@a9g2000prl.googlegroups.com:
Thank you all for responding. Your input helped clear things a lot.
Along those same lines, if you plan on
unloading your dlls make very sure that every object allocated from
that dll has been destroyed first or you will get a fault when you
eventually do get around to destroying those objects. Something
about the destructors not being loaded into memory any more makes the
system get upset. :)
This excerpt from Effective C++, Iterm 18 adds to what you said:
"An especially nice feature of tr1::shared_ptr is that it
automatically uses its per-pointer deleter to eliminate another
potential client error, the "cross-DLL problem." This problem crops
up when an object is created using new in one dynamically linked
library (DLL) but is deleted in a different DLL. On many platforms,
such cross-DLL new/delete pairs lead to runtime errors.
tr1:;shared_ptr avoids the problem, because its default deleter uses
delete from the same DLL where the tr1::shared_ptr is created."
And that is true. The problem with STL collections is that they can sneak
an allocation in on you for one of their internal structures and the
current versions don't take any steps to guarantee that the internal
structure gets deleted where it was allocated. AFAIK, this is a problem
only for classes where the implementation is all in the header, allowing
for the inlining of methods that may allocate memory.
joe