当我只能覆盖new和delete时，为什么要为STL容器编写自定义分配器？

如何解决当我只能覆盖new和delete时，为什么要为STL容器编写自定义分配器？

我想编写一个自定义的内存管理器/分配器以进行学习。我很想拥有一个主分配器，该分配器从堆中请求n个字节的ram（通过new）。接下来是几个分配器...适配器？每个服务器都将与主服务器接口，请求一个内存块进行管理，它们是堆栈，线性，池，平板分配器等，每个都从其主池分配器的片中管理分配。

我遇到的问题是我是否应该编写自定义allocator_traits以与各种STL容器的接口交互；或者，如果我只是忽略适配器的想法，而只是简单地重载new和delete以使用自定义池分配器/管理器（即主池）。

我有兴趣了解的是，为STL容器使用单独的分配器会带来什么明显的好处？似乎默认的std :: allocator会根据需要调用new和delete，因此，如果我重载了这些内容，而是从我的大型自定义内存池中进行请求，那么我将获得所有好处，而无需编写std :: allocator自定义代码。 >

或者这是某些类型的分配器模型（例如为std :: deque使用堆栈分配器）比默认分配器更好地解决问题吗？如果是这样，那么普通的stl实现是否已经不会为各种容器类型专门设置默认分配器，或者是否在对默认分配器的调用中进行了优化？

如果真的很重要，我正在通过GCC 10+使用C ++ 20

解决方法

如果要替换全局分配器（包括正在使用的每个库中的分配器），则不必使用std::allocator。

std分配器使您可以执行诸如创建临时分配池之类的操作。假设您有一些可以保证不会超出某个范围的数据结构，并且您知道（无论分配了什么）90％+仍将分配给范围的末尾。

一个相对简单的std分配器可以比其他全局new或delete操作员更快地分发内存，从不回收内存并在作用域末尾对其进行清理。

只要您对容器的内容和生存期有特殊的了解，就可以手动调整该特定容器的分配器。标准分配器不能。有时，当您愿意妥协std容器不希望这样做时，可以使用自定义分配器修补其行为。

std::deque无法有效地使用堆栈分配器，因为它不能假定您主要将其用作堆栈。您可能主要将其用于队列。当您将堆栈分配器主要用作队列时，这将是一场灾难。但是如果您将其90％+用作堆栈，则堆栈分配器可能会以适度的内存开销为代价（如果为99％+，则该堆栈分配器可处理异常情况并清理基于非堆栈的操作）会更快得多）。

最后，分配器可以允许您区分各种容器。您可能希望将文档（持久）状态的内存分配到内存的一个区域中，而将“临时”非持久数据分配到其他位置。

是的，您应该考虑不要使用std分配器。优化是可替代的，对低级内存分配进行调整是使系统的其余部分更高效，更功能后可以进行的工作。仅当您有可行的东西，还不够快，并且已经将新/删除确定为无法设计的基本瓶颈时，才应该说“确定，该更换分配了！”

,

依次回答两个问题：

我应该编写自定义allocator_traits来连接各种STL容器的分配器吗？

是的，易于操作。在实施的不久，就会出现诸如控制内存重叠的情况。例如，在对各个分配器的全部功能进行压力测试并确定重新分配算法的同时。在这方面，您将需要专门针对分配器的allocator_traits类，而不是使用member types和new运算符从头开始实现其delete。

使用allocator_traits的原因是因为它便于轻松地处理需要遵守的某些规则。这些规则在整个内存管理中都会发生。 [在构造分配器时，请参考here的三个此类规则。]

通过为STL容器使用单独的分配器，我将获得什么明显的好处？

对主分配器如何分配，重新分配，复制，移动和销毁内存的绝对控制（增加了对量化/增强性能的控制）。很酷，不是吗！如果使用默认的std分配器，则您将失去此控件，而依赖于（尽管非常好）默认的内存管理实现。