On Fri, Aug 23, 2019 at 2:12 PM Andrey Semashev via Boost < boost@lists.boost.org> 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