On Mon, 22 Jun 2020 at 09:32, Zach Laine via Boost
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.