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.

Answer 3

If you're concerned, use the form of shared_ptr constructor that takes a deleter argument. The deleter can call back into the module that allocated the object so that the delete occurs in the proper context.

Boost's documentation claims it is 100% compatible with TR1, so hopefully there's nothing misleading about this:

http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/shared_ptr.htm#constructors

Answer 4

I'd guess it is as safe as to use any of the classes in std across modules.

That is: It should be safe if the modules use exactly the same runtime library, and exactly the same compiler switches and options.

Never use the static runtime library, as each module will get their own instance of all globals within it.

Answer 5

The best advice I've seen on the general subject is that memory should be deallocated in the same context it's allocated. That doesn't preclude a library passing back a pointer that application code is supposed to free however, so I'd say you're probably safe passing the shared_ptr in this manner, as it's the same general situation.

If the semantics of your system mean that the pointer is actually transferred (in the ownership sense) from your exe to your dll, then an auto_ptr might be a better solution. If, however, your pointer is truly shared, then the shared_ptr is probably the best solution.