Home/ Questions/Q 89761
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T22:46:02+00:00

I know that new-ing something in one module and delete-ing it in another can

  • 0

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).

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 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.

    • 0