Re: Requesting endorsements of Boost.STLInterfaces for review

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