增强池分配
为什么 boost::fast_pool_allocator 构建在单例池之上，而不是每个分配器实例都有一个单独的池？或者换句话说，为什么只提供这一点，而不是为每个分配器提供一个池的选项？这是一个坏主意吗？
我有一个类在内部使用大约 10 种不同的 boost::unordered_map 类型。如果我使用了 std::allocator，那么当它调用删除时，所有内存都会返回到系统，而现在我必须在某些时候对许多不同的分配器类型调用release_memory。 我会愚蠢地推出自己的使用 pool 而不是 singleton_pool 的分配器吗？
谢谢
Why is the boost::fast_pool_allocator built on top of a singleton pool, and not a separate pool per allocator instance? Or to put it another way, why only provide that, and not the option of having a pool per allocator? Would having that be a bad idea?
I have a class that internally uses about 10 different boost::unordered_map types. If I'd used the std::allocator then all the memory would go back to the system when it called delete, whereas now I have to call release_memory on many different allocator types at some point.
Would I be stupid to roll my own allocator that uses pool instead of singleton_pool?
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
分配器很难拥有状态，因为分配器的所有实例都必须“等效”才能被标准库使用（至少可移植）。
从 20.1.5/4“分配器要求”开始：
给定分配器类型的所有实例都需要可互换，并且始终 继续说道：
因此，可以编写一个实现来允许非等效的分配器实例，但是您的分配器依赖于实现定义的行为。
请参阅这个其他SO答案了解一些额外的信息详细信息（看起来我需要对该答案进行一些承诺的更新......）
It's difficult for an allocator to have state, since all instances of an allocator had to be 'equivalent' to be used by the standard library (at least portably).
From 20.1.5/4 "Allocator requirements":
It then goes on to say:
So an implementation can be written to allow non-equivalent allocator instances, but then your allocator is dependent in implementation-defined behavior.
See this other SO answer for some additional details (and it looks like I need to tend to some promised updating of that answer...)