是否有一个 STL 分配器不会隐式释放内存？
我的 STL 容器中的内存使用量预计是不稳定的 - 也就是说，它会频繁地收缩和增长。我正在考虑通过为 STL 容器类型声明指定分配器来解决这个问题。我知道池分配器旨在处理这种类型的情况，但我担心波动性将超过池所考虑的范围，为了克服它，我必须进行大量测试以确定良好的池指标。
我理想的分配器永远不会隐式释放内存，事实上，如果内存仅在分配器销毁时释放，那么这是完全可以接受的。显式释放未使用内存的成员函数会很好，但不是必需的。我知道我所说的听起来像是每个对象的分配器，这违反了标准。我宁愿坚持这个标准，但如果我不能在其中解决这个问题，我就会放弃它。
我不太关心初始表现，更关心平均表现。换句话说，一次分配单个元素还是一组元素并不重要，更重要的是所述分配是否会导致对 new/malloc 的调用。我编写自己的分配器没有问题，但是有人知道现有的分配器可以实现这一目标吗？如果有区别的话，这将适用于连续的内存容器（例如向量、双端队列），尽管通用的解决方案会很好。
Memory usage in my STL containers is projected to be volatile - that is to say it will frequently shrink and grow. I'm thinking to account for this by specifying an allocator to the STL container type declarations. I understand that pool allocators are meant to handle this type of situation, but my concern is that the volatility will be more than the pool accounts for, and to overcome it I would have to do a lot of testing to determine good pool metrics.
My ideal allocator would never implicitly release memory, and in fact is perfectly acceptable if memory is only ever released upon destruction of the allocator. A member function to explicitly release unused memory would be nice, but not necessary. I know that what I'm referring to sounds like a per-object allocator and this violates the standard. I'd rather stick with the standard, but will abandon it if I can't resolve this within it.
I am less concerned with initial performance and more with average performance. Put another way, it matters less whether a single element or a pool of them is allocated at a time, and more whether said allocation results in a call to new/malloc. I have no problem writing my own allocator, but does anyone know of a preexisting one that accomplishes this? If it makes a difference, this will be for contiguous memory containers (e.g. vector, deque), although a generalized solution would be nice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我希望这不是太基础。
添加项目时分配和释放的内存会比删除项目时分配和释放的内存更多。
我相信，除非您知道应用程序允许的最大元素数，否则永远不可能“释放”内存。 CRT 可能会尝试就地分配更大的内存块，但是如何处理失败情况呢？
说明：
要创建动态扩展向量，将有更大的容量来处理大多数push_backs，并在容量不足时进行重新分配。
并将旧内存的元素复制到新内存中
一。
在push_back时不要持有任何迭代器，这一点很重要
元素，因为重新分配会使内存失效
迭代器指向的位置。
在 c++11 和 TR1 中，您可能拥有完美的转发，其中只有
指向需要复制的元素的指针。这是通过移动完成的
构造函数而不是复制构造函数。
但是，您似乎希望尽可能避免重新分配。
使用向量的默认分配器，您可以指定初始容量。
Capacity 是分配的内存，size 是元素的数量。
内存只会在构造时分配，并且大小达到
容量。这应该只发生在 Push_back() 中；
默认分配器会将容量增加数倍（例如
1.5, 2.0)，以便重新分配在线性时间内发生。因此，如果您有一个推回数据的循环，那么它是线性的。或者，如果您提前知道元素数量，则可以分配一次。
您可以探索一些池概念。池的想法是你不是破坏元素而是停用它们。
如果您仍然想编写自己的分配器，这是一篇好文章。
自定义分配器
I hope this isn't too basic.
Memory will be allocated and freed more for adding items than removing them.
I believe that never "freeing" memory isn't possible unless you know the maximum number of elements allowed by your application. The CRT might try to allocate a larger block of memory in place, but how would you handle the failure cases?
Explaination:
To create a dynamically expanding vector, there will be a larger capacity to handle most push_backs, and a reallocation to handle when this is insufficient.
and the elements of the old piece of memory are copied into the new
one.
It is important that you don't hold any iterators while to push_back
elements, because the reallocation will invalidate the memory
locations the iterator point to.
In c++11 and TR1, you might have perfect forwarding where only the
pointer to the elements need to be copied. This is done via a move
constructor instead of a copy constructor.
However, you seem to want to avoid reallocation as much as possible.
Using the default allocator for vector you can specify an initial capacity.
Capacity is the memory allocated and size is the number of elements.
Memory will only be allocated at construction and if the size reaches
capacity. This should only happen with a push_back();
The default allocator will increase the capacity by a multiple (eg.
1.5, 2.0) so that reallocation takes place in linear time. So if you have a loop that pushes back data it's linear. Or if you know the number of elements ahead of time you can allocate once.
There are pool concepts you can explore. The idea with a pool is you are not destroying elements but deactivating them.
If you still want to write your own allocator, this is a good article.
custom allocators