Is it safe to use STL (TR1) shared_ptr's between modules (exes and dlls)

Question

I know that new-ing something in one module and delete-ing it in another can often cause problems in VC++. Problems with different runtimes. Mixing modules with staticly linked runtimes and/or dynamically linked versioning mismatches both can screw stuff up if I recall correctly.

However, is it safe to use VC++ 2008's std::tr1::shared_ptr across modules?

Since there is only one version of the runtime that even knows what what a shared_ptr is, static linking is my only danger (for now...). I thought I've read that boost's version of a shared_ptr was safe to use like this, but I'm using Redmond's version...

I'm trying to avoid having a special call to free objects in the allocating module. (or something like a "delete this" in the class itself). If this all seems a little hacky, I'm using this for unit testing. If you've ever tried to unit test existing C++ code you can understand how creative you need to be at times. My memory is allocated by an EXE, but ultimately will be freed in a DLL (if the reference counting works the way I think it does).

Answer 1

Freeing the memory is safe, so long as it all came from the same memory management context. You've identified the most common issue (different C++ runtimes); having separate heaps is another less-common issue you can run into.

Another issue which you didn't mention, but which can be exascerbated by shared pointers, is when an object's code exists in the DLL and is created by the DLL, but another object outside the DLL ends up with a reference to it (via shared pointer). If that object is destroyed after the DLL is unloaded (for example, if it's a module-level static, or if the DLL is explicitly unloaded by FreeLibrary(), the shared object's destructor will crash.

This can bite you if you attempt to write DLL-based, loosely-coupled plugins. It's also the reason that COM lets DLLs decide when they can be unloaded, rather than letting COM servers demand-unload them.

Answer 2

You're beginning to see how incredibly amazing shared_ptr is :)

Being safe across DLL boundaries is exactly what shared_ptr was designed to be (among other things, of course).

Contrary to what others have said, you don't even need to pass a custom deleter when constructing the shared_ptr, as the default is already something like

template <typename T>
struct default_deleter {
    void operator()( T * t ) { delete t; }
};

and

shared_ptr<Foo> foo( new Bar );

is equivalent to

shared_ptr<Foo> foo( new Bar, default_deleter<Bar>() );

(ie. there's no such thing as a shared_ptr without a deleter).

Because of the type erasure performed on the deleter, the delete that's called will always be the one from the DLL that instantiated the shared_ptr, never the one from the DLL where the last shared_ptr goes out of scope (ie. the shared_ptr invoking the deleter will call it through a pointer to a function put there by the original shared_ptr).

Compare this to auto_ptr, which embeds the delete operator directly in its (inline) destructor, which means that the delete of the DLL that destroys the auto_ptr is used, creating the same problems as deleting a naked pointer.

By the same technique, polymorphic classes that are always held in shared_ptrs don't even need a virtual destructor, because the deleter will always call the right destructor, even when the last shared_ptr to go out of scope is one instantiated for the base class.