Re: Requesting endorsements of Boost.STLInterfaces for review

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