From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-08-23 19:58:38
On Fri, Aug 23, 2019 at 2:12 PM Andrey Semashev via Boost <
> 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
> > 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.
As I stated previously, this discussion is thoroughly moot. I cannot do
anything in a CRTP base class like container_interface to help those who
want to create allocator-aware containers.
Your feelings about the allocator abstraction -- and mine as well -- are
irrelevant to any discussion of stl_interfaces. If you care enough about
this debate to start another thread, I'll follow you there.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk