Re: Requesting endorsements of Boost.STLInterfaces for review

From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2019-09-09 08:08:04

> On 23. Aug 2019, at 21:58, Zach Laine via Boost <boost_at_[hidden]> wrote:
> 
> 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.

I think Andrey gave you some very good arguments and we are not discussing personal choices here. Allocators are part of the STL and Boost. You need to adhere to these design choices if you want to write a generic C++ component that may be part of the STL some day. That it is too much effort for you is not a viable argument. Your arrogant and dismissive attitude is not helping your cause either. You are not becoming a first class C++ author by rejecting good advice.