c++ - 跨 dll 边界的内存分配和释放

Question

我知道在一个 dll 中进行的内存分配随后在另一个 dll 中释放会导致各种问题，尤其是与 CRT 相关的问题。在导出 STL 容器时，这些问题尤其严重。我们以前遇到过这类问题(在编写与我们的库链接的自定义 Adob​​e 插件时)，我们通过定义我们自己的分配器来解决这些问题，我们在所有容器中使用它，例如:

typedef std::vector < SessionFields, 
        OurAllocator < SessionFields > > 
        VectorSessionFields;

typedef std::set < SessionFields, 
        std::less < SessionFields >, 
        OurAllocator < SessionFields > > 
        SetSessionFields;

这在向我们的代码传递类型或从我们的代码传递类型时效果很好，但是我们遇到了一个问题，因为我们现在必须调用 Adob​​e SDK 中的一个函数，该函数返回一个填充的 vector ，当它退出时会导致崩溃范围。

显然，当我的代码最终释放内存时，Adobe 的 SDK 中属于不同堆的内存分配存在问题。所以我在想，也许我可以做一些聪明的事情，比如以某种方式覆盖或导出他们 SDK 中使用的分配器，这样我就可以用它来清理从他们的函数返回的容器。

我也在考虑编写一个包装器或某种类型的 thunking 层，从而在我的代码和 SDK 之间安全地编码 STL 容器(尽管这听起来确实很困惑)。

或者，我也在考虑使用 GetProcessHeaps 来识别从 SDK 中使用的堆，并尝试释放这个堆，而不是默认堆。

有没有人对我们如何解决这个问题有任何建议？

Answer 1

具有讽刺意味的是，Adobe 源库有一个 adobe::capture_allocator专门为这种 DLL 安全而编写的类。它的工作方式是在实例化时捕获本地 new 和 delete，并在对象的生命周期内携带它们。 (请参阅 adobe::new_delete_t 以了解有关它如何执行此操作的详细信息，尤其是实现 here 。)释放发生在捕获的 delete 例程中，保证无论您身在何处，都可以使用正确的方式进行删除删除。

您可以看到 capture_allocator 在整个 version_1 中使用Adobe 源库中的类型，例如 adobe::any_regular_t和 adobe::copy_on_write . capture_allocator 也应该与所有 STL 容器类型兼容。

更新:capture_allocator 不符合标准，因为它保留状态。这应该不会对其可用性构成很大的障碍，但这确实意味着它的使用不能保证与符合标准的容器一起使用。