c++ - C++库应如何允许自定义分配器？

Question

在C语言中，对于库而言，允许用户使用全局函数指针来自定义与malloc()类似的功能以及与free()类似的功能的自定义内存分配很简单。例如，SQLite使用这种方法。

C++使事情变得有些复杂，因为分配和初始化通常是融合在一起的。从本质上讲，我们希望获得仅对库重写operator new和operator delete的行为，但是实际上无法做到这一点(我很确定，但不是100％)。

应该如何在C++中完成？

Here是用某种功能new复制Lib::make<T>表达式的某些语义的工具。

我不知道这是否有用，但只是为了好玩，here是一个更复杂的版本，它也尝试复制new[]表达式的语义。

这是一个面向目标的问题，因此我不必寻找代码审查。如果有更好的方法可以这样做，请忽略链接。

(“分配器”仅表示分配内存的内容。我不是在指的是STL分配器概念，甚至没有必要为容器分配内存。)

为什么这可能是理想的:

Here是Mozilla开发人员的博客文章，争论说图书馆应该这样做。他列举了一些C库的示例，这些示例允许库用户自定义库分配。我 check out 了其中一个示例SQLite的源代码，并看到此功能还内部用于通过故障注入(inject)进行测试。我没有写任何需要像SQLite一样防弹的东西，但这似乎仍然是一个明智的主意。如果没有其他要求，它可以让客户端代码弄清楚“哪个库正在占用我的内存，何时占用我的内存？”。

Answer 1

简单的答案:不要使用C++。对不起，开 Jest 。

但是，如果您想对C++中的内存管理进行这种绝对控制，可以跨库/模块的边界，并且以一种完全通用的方式进行，那么您可能会有些痛苦。我建议大多数人寻找不这样做的原因，而不是这样做的方法。

多年来(实际上是几十年)，我经历了相同基本思想的多次迭代，从尝试在全局范围内天真地重载运算符new/new []/delete/delete []到基于链接程序的解决方案(针对特定平台)解决方案，实际上我现在正处于理想的状态:我有一个系统，可以让我查看每个插件分配的内存量。但是我并没有通过您想要的一种通用方式来达到这一点(最初也是我)。

C++ complicates things a bit because allocation and initialization are usually fused.

我会稍微改变一下这一说法:C++使事情变得复杂，因为初始化和分配通常是融合在一起的。我所做的只是在这里交换顺序，但是最复杂的部分不是分配要初始化，而是因为初始化经常要分配。

举个基本的例子:

struct Foo
{
    std::vector<Bar> stuff;
};

在这种情况下，我们可以通过自定义内存分配器轻松分配Foo:

void* mem = custom_malloc(sizeof(Foo));
Foo* foo = new(foo_mem) Foo;
...
foo->~Foo();
custom_free(foo);

...当然，我们可以包装所有我们想遵守的RAII，实现异常安全性等。

除了现在，问题是级联的。使用 stuff的 std::vector成员将要使用 std::allocator，现在我们要解决第二个问题。我们可以使用我们自己的分配器使用 std::vector的模板实例化，如果需要将运行时信息传递给分配器，则可以覆盖Foo的构造函数，以将该信息与分配器一起传递给 vector 构造函数。

但是 Bar呢？它的构造函数还可能希望为各种不同的对象分配内存，因此问题会层叠，层叠和级联。

考虑到这个问题的难度，以及我尝试过的替代性通用解决方案以及移植时的悲伤，我选择了一种完全去概括性的，有些务实的方法。

我确定的解决方案是有效地重新创建整个C和C++标准库。我知道令人恶心，但就我而言，我有更多的借口。我正在研究的产品实际上是一个引擎和软件开发套件，旨在使人们可以使用任何编译器，C运行时，C++标准库实现以及所需的构 build 置为其编写插件。为了允许 vector ，集合或映射之类的东西以与ABI兼容的方式通过这些中央API传递，除了许多C标准函数之外，还需要滚动我们自己的符合标准的容器。

然后，此devkit的整个实现围绕以下分配功能进行:

EP_API void* ep_malloc(int lib_id, int size);
EP_API void ep_free(int lib_id, void* mem);

...并且整个SDK围绕这两个，包括内存池和“子分配器”。

对于我们无法控制的第三方库，我们只是SOL。这些库中的一些库具有与它们的内存管理一样的宏伟目标，并且试图覆盖它们会导致各种冲突并打开各种蠕虫病毒。在使用类似OGL之类的东西时，也有非常低级的驱动程序想要分配大量的系统内存，而我们对此无能为力。

但是我发现此解决方案可以很好地回答以下基本问题:“谁/什么占用了所有这些内存？”很快:一个问题通常比与时钟周期相关的问题要难得多(对此我们可以启动任何分析器)。它仅适用于使用此SDK的受我们控制的代码，但使用此系统可以按模块对内存进行彻底的故障分析。我们还可以对内存使用量设置表面上的上限，以确保实际上正确处理了内存不足错误，而没有实际尝试耗尽系统中所有可用的连续页面。

因此，在我的情况下，此问题是通过政策解决的:通过建立统一的编码标准和一个与之兼容的中央库，该标准将在整个代码库中使用(并由第三方为我们的系统编写插件)。它可能不是您要找的答案，但这最终是我们找到的最实用的解决方案。