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

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 2

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.

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

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.