|
Boost : |
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-08-23 15:39:50
On Fri, Aug 23, 2019 at 2:35 AM Hans Dembinski via Boost <
boost_at_[hidden]> wrote:
>
> > On 23. Aug 2019, at 09:22, Gavin Lambert via Boost <
> boost_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk