Boost logo

Boost :

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 <
boost_at_[hidden]> wrote:

> 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
> Boost.Whatever.
>
> 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.

Zach


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk