我的STL容器中的内存使用量预计会不稳定 - 也就是说它会经常收缩和增长。我想通过为STL容器类型声明指定一个分配器来解决这个问题。我知道池分配器是为了处理这种情况，但我担心的是波动性将超过池的帐户，为了克服它，我必须做很多测试来确定良好的池指标。 / p>
我理想的分配器永远不会隐式释放内存，实际上如果只在销毁分配器时才释放内存，这是完全可以接受的。显式释放未使用的内存的成员函数会很好，但不是必需的。我知道我所指的听起来像是一个每个对象的分配器，这违反了标准。我宁愿坚持标准，但如果我不能在其中解决这个问题，我会放弃它。
我不太关心初始性能，而是更关注平均性能。换句话说，一次分配单个元素或它们的池是否重要，更重要的是所述分配是否导致调用new / malloc。我编写自己的分配器没有问题，但是有没有人知道预先存在的分配器能够完成吗？如果它有所不同，这将是连续的内存容器（例如vector，deque），尽管通用解决方案会很好。
答案 0 :(得分：1)
我希望这不是太基础。
我相信除非您知道应用程序允许的最大元素数，否则永远不会“释放”内存。 CRT可能会尝试分配更大的内存块，但您如何处理故障情况呢？
阐释：
要创建动态扩展向量，将有更大的容量来处理大多数push_backs，并在需要时重新分配以进行处理。
重要的是，在push_back时不要持有任何迭代器 元素，因为重新分配将使内存无效 迭代器指向的位置。
在c ++ 11和TR1中，您可能只有完美转发 需要复制指向元素的指针。这是通过移动完成的 构造函数而不是复制构造函数。
但是，您似乎希望尽可能避免重新分配。
容量是分配的内存，size是元素的数量。
内存只会在构造时分配，如果大小达到 容量。这应该只发生在push_back（）;
默认分配器会将容量增加一倍（例如。 1.5,2.0）以便重新分配在线性时间内进行。因此，如果你有一个循环推回数据它是线性的。或者，如果您提前知道元素数量，则可以分配一次。
您可以探索游泳池概念。游泳池的想法是你不是破坏元素，而是停用它们。
如果您仍想编写自己的分配器，这是一篇很好的文章。