DLL内存管理器mixup [英] DLL memory manager mixup

问题描述

我写了一个应用程序，允许人们提供插件来扩展功能。这样的插件被部署为DLL文件，框架在运行时拾取。每个插件都有一个工厂函数，它在应用程序的生命周期中被多次调用以创建对象。到目前为止，为了处理这些对象的所有权问题，我在返回的对象上使用了一个简单的计数共享指针，以便在删除最后一个引用时被销毁。

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 runtime. Each plugin features a factory function which is called multiple times during the lifetime of the application to create objects. So far, in order to handle the ownership issue with these objects, I used a simple counting shared pointer on the returned objects so that they are destroyed whenever the last reference is removed.

但是，这往往会触发Windows上的崩溃，因为这不是不可能发生的对象是新的在插件DLL，但以后（由于对共享指针的deref（）调用）在主应用程序中删除 - AFAIK这个malloc / free mixup是一个没有在Windows上。

However, this tends to trigger crashes on Windows since it's not unlikely to happen that the object is new'ed in the plugin DLL but later (due to a deref() call on the shared pointer) deleted in the main application - and AFAIK this malloc/free mixup is a no-no on Windows.

我现在的解决方案是让deref（）不直接调用'delete this;一个'release（）;'函数必须由插件实现和调用'delete this;'。然而，这是非常恼人的每个插件必须实现这个琐碎的功能 - 我通过提供一个方便的宏插件作者必须使用到目前为止。有人可能有替代的想法吗？

My current solution to this is to let deref() not call 'delete this;' directly but rather a 'release();' function which must be implemented by the plugins and calls 'delete this;'. However, it's quite annoying that each and every plugin has to implement this trivial function - I worked around this so far by providing a convenience macro plugin authors have to use. Does anybody have alternative ideas maybe?

到目前为止，我的方法是所有由插件贡献的对象在插件中分配，并发布在那里 - 当然，是让所有内存在主应用程序中分配（通过向插件提供一个malloc类函数的指针，然后他们可以根据需要调用），并在那里释放。这个问题是，它不是那么方便的插件作者，我想。

So far, my approach is that all objects contributed by plugins is allocated in the plugins and also released there - of course, an alternative might be to let all memory be allocated in the main application (by providing a pointer to a malloc-like function to the plugins which they can then call as needed) and released there as well. The issue with this is that it's not as convenient for the plugin authors, I think.

我会对这个问题的任何其他观点感兴趣。

I'd be interested in any other perspectives on this issue.

UPDATE：我刚刚意识到，我可以在插件返回的对象的基类上重新实现操作符new和operator delete，以便新建它们删除它们将总是导致函数调用到同一个模块（所以所有的分配和自由的是在插件，或在框架中完成）。

UPDATE: I just realized that I could reimplement operator new and operator delete on the baseclass of the objects returned by the plugins, so that new'ing them and delete'ing them will always result in function calls into the same module (so that either all allocations and free's are done in the plugin, or in the framework).

推荐答案

有两种解决方案。解决方案之一是共享更多 - 如果双方使用相同的CRT DLL（/ MD或/ MDd在MSVC），你可以移动新的/删除DLL边界。解决方案二是共享更少 - 让每个DLL有自己的C ++堆，不要跨越DLL边界拆分新的/删除。

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.

这篇关于DLL内存管理器mixup的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！