c++ - 是否有不会隐式释放内存的 STL 分配器？

Question

我的 STL 容器中的内存使用预计是不稳定的——也就是说它会经常收缩和增长。我正在考虑通过为 STL 容器类型声明指定一个分配器来解决这个问题。我知道矿池分配器旨在处理这种情况，但我担心的是波动性将超过矿池所占的比例，为了克服它，我将不得不进行大量测试以确定良好的矿池指标。

我理想的分配器永远不会隐式释放内存，事实上，如果内存只在分配器销毁时释放，那是完全可以接受的。显式释放未使用内存的成员函数会很好，但不是必需的。我知道我指的是听起来像每个对象的分配器，这违反了标准。我宁愿坚持标准，但如果我不能在其中解决这个问题，我会放弃它。

我不太关心初始性能，而更关心平均性能。换句话说，一次分配单个元素还是它们的池并不重要，重要的是所述分配是否导致调用 new/malloc。我编写自己的分配器没有问题，但是有谁知道可以完成此任务的现有分配器吗？如果它有所作为，这将适用于连续的内存容器(例如 vector、deque)，尽管通用的解决方案会很好。

Answer 1

我希望这不是太基础。

将分配和释放内存更多用于添加项而不是删除项。

我相信除非您知道您的应用程序所允许的元素的最大数量，否则永远不会“释放”内存。 CRT 可能会尝试就地分配更大的内存块，但您将如何处理失败情况？

解释:

要创建动态扩展 vector ，将有更大的容量来处理大多数 push_backs，并在容量不足时重新分配以处理。

• 在重新分配期间，“更新”了一 block 新的更大的内存并将旧内存中的元素复制到新内存中一个。

• 重要的是在 push_back 时不要持有任何迭代器元素，因为重新分配会使内存失效
  迭代器指向的位置。

• 在 c++11 和 TR1 中，您可能拥有完美转发，其中只有指向需要复制的元素的指针。这是通过移动完成的构造函数而不是复制构造函数。

但是，您似乎想尽可能避免重新分配。

使用 vector 的默认分配器，您可以指定初始容量。

• 容量是分配的内存，大小是元素的数量。

• 内存只会在构造时分配，如果大小达到容量。这应该只发生在 push_back();

• 默认分配器会将容量增加数倍(例如1.5, 2.0) 以便重新分配发生在线性时间内。因此，如果您有一个将数据推回的循环，那么它是线性的。或者，如果您提前知道元素的数量，您可以分配一次。

您可以探索池概念。池的想法是您不是在破坏元素，而是在停用它们。

如果您还想编写自己的分配器，这是一篇很好的文章。

custom allocators