[Boost-users] Re: Using shared_ptr across shared library boun dary

From: David Abrahams (dave_at_[hidden])
Date: 2004-03-12 08:00:20

Ferdinand Prantl <ferdinand.prantl_at_[hidden]> writes:

>> From: David Abrahams [mailto:dave_at_[hidden]] 
>> > "Jim.Hyslop" <Jim.Hyslop_at_[hidden]> writes:
>> > It's been my experience
>> > (with Visual Studio, at least) that allocating memory in 
>> > one DLL and 
>> > deallocating it in another leads to problems. Sometimes it 
>> > doesn't go 
>> > noticed, but when it does, it's really noticeable.
>> 
>> The library cleverly avoids that, provided the first 
>> shared_ptr to take ownership of the memory does so in the 
>> same DLL where the object was allocated.
>
> Actually, I came into the same problem as Jim - I had to
> ensure the same version of the msvcrt and moreover its
> debug/release versions to get the code working well.
>
> All classes in checked_delete.hpp, smart_count.hpp and shared_ptr.hpp
> are either templates or completely in headers. The operations with
> new/delete and allocators are translated/inlined by the compiler into
> every unit, IMHO.
>
> I could not find the trick in the implementation, how to force
> the deletion of the pointer by the same runtime, if new() was
> performed in one DLL and delete() in another one. 

That never happens as long as the shared_ptr takes ownership in the
same DLL where the new() occurs.  At the point the raw pointer is
acquired by the shared_ptr, a templated deleter is instantiated; it
has knowledge not only of the correct heap but also the full type of
the raw pointer.  delete is always performed by dynamic dispatch.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com