From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-08-23 19:12:25
On 8/23/19 6:39 PM, Zach Laine via Boost wrote:
> 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.
Container properties, like element contiguity, list and complexity of
operations, etc., and memory allocator are conceptually distinct.
Implementing a container over a non-customizable allocator is viable as
long as the allocator fits your use case. Which is unlikely to be the
case when the container is part of a public generic library, such as
Furthermore, asking people to reimplement the container just to change
the allocator is simply unreasonable. Implementation complexity of a
container is often higher than that of an allocator, given that it often
comes down to one of the function families like
malloc/aligned_alloc/free. Even if it doesn't, an allocator should not
be part of the container implementation anyway.
Standard containers may be unnecessarilly complicated by the current
allocator handling convention, but conceptually, that the container and
the allocator are separate, is the right design choice.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk