Boost logo

Boost Users :

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

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net