DLL memory manager mixup

Question

I wrote an application which allows people to contribute plugins to extend the functionality. Such plugins are deployed as DLL files, which the framework picks up during run

Answer 1

There are two solutions. Solution one is "share more" - you can move new/delete across DLL boundaries if both sides use the same CRT DLL (/MD or /MDd in MSVC). Solution two is "share less" - let each DLL have its own C++ heap, and do not split new/delete across DLL boundaries.

Answer 2

If the DLL code is responsible for allocating objects, it should also be responsible for freeing them. I think your problem is more with the reference counting and the "delete this". If you want to go that route, why not simply implemnt the objects as COM objects? This is after all one of the main problems that COM was designed to solve!

Answer 3

It turned out that the easiest way to make sure that memory is not allocated in one DLL and released in another is this: reimplement operator new and operator delete on the base class of the objects which are returned from the plugins. In the implementations of these functions, call 'alloc' and 'free' functions (which have been passed from the main application when loading the plugin). That way, plugins can keep using 'new' and 'delete' but the memory will actually be allocated and released in the main application.