Re: Boost.Text review

From: Ville Voutilainen (ville.voutilainen_at_[hidden])
Date: 2020-06-22 14:53:15

On Mon, 22 Jun 2020 at 09:32, Zach Laine via Boost
<boost_at_[hidden]> wrote:
> > I don't mind that the string isn't templated on the char type,
> > but I do miss the allocator support; I've used strings with arena
> > allocators (for performance) and with shared memory allocators.
> > I know allocator support is a lot of work but it is necessary, IMO.
>
> I disagree.  Allocators are a poor design, in that they are too
> general.  Consider std::vector.  An insert operation has different
> optimal implementations depending on whether the vector is a fixed
> capacity, inline-storage type or a heap-allocated type.  An allocator
> changed the allocation strategy, but leaves all the other code that
> often depends on the allocation semantics unchanged.  A better design
> is to have a separate templates for inline storage (e.g.
> boost::container::static_vector), sbo-optimized heap storage (e.g.
> boost::container::small_vector), and heap storage (e.g. std::vector).
> Many other libraries have come to the same conclusion, including FB
> Folly, LLVM's internal lib, and more.

I don't claim to understand the details of insertion for different-type vectors,
but the container<->allocator interface certainly cannot really communicate
a whole lotta things that a container might want to tell the allocator, like
"I'm going to be replacing this old allocation with this new allocation", and
"I'm going to be allocating this many elements with individual allocations,
but I'm not seeking to allocate an array". Such things can be communicated
straight-to-the-allocator in an allocator-specific way outside the container's
control, but there's no generic interface for that sort of hinting, which has
always seemed quite funny to me, considering that memory allocation
is the allocator's responsibility, but things that might have an immense
impact on the proper allocation strategy that should be selected are not hinted
to the allocator. And they're not necessarily static.