Re: STL objects and binary compatibility

osama178@[EMAIL PROTECTED]
 wrote in
news:740ee874-4c83-42a5-8bcd-5dad161e1f38@[EMAIL PROTECTED]
 

> 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 cl***** where the implementation is all in the header, allowing 
for the inlining of methods that may allocate memory.

joe