Ferdinand Prantl <ferdinand.prantl@ixos.de> writes:

...

From: David Abrahams [mailto:dave@boost-consulting.com]

...

"Jim.Hyslop" <Jim.Hyslop@Leitch.com> 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