On Fri, Aug 23, 2019 at 2:35 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:
On 23. Aug 2019, at 09:22, Gavin Lambert via Boost < boost@lists.boost.org> wrote:
I don't really write new iterators or containers very often, and when I do, it's usually the allocators that are the pain point.
I second that.
So do I. But that does not mean you need help making allocator-aware containers. That means you need to stop making them. The bang-for-buck is terrible. How much time and complexity increase is required to add allocator support? And how many instantiations of your container C will use a non-default allocator? It is never worth it, unless you work at a place like Bloomberg, where heavy allocator use is part of the culture. Here are the allocator requirements: http://eel.is/c++draft/containers#tab:container.alloc.req . They are all special member functions, constructors, one typedef, and member swap(). A CRTP base cannot help you with even one of those. Even if I could do something to make allocator-aware containers easier to write, I would not, simply because the whole point of making container_interface is to make container authoring straightforward. If multiple allocation strategies are actually important, write multiple containers, each with the different strategy. The allocation scheme you use is an inherent part of the class's invariant maintenance, despite what the standard library would have you think. Zach