Is a revision of the std::allocator interface planned for future C++ versions?

Question

In a talk from 2015 Andrei Alexandrescu outlines some atrocities of the std::allocator interface, shortly highlighting how it's not in fact about allocation and proposing a different way of thinking about these allocators that would make them more usable and modular. Or, to quote from the description:

std::allocator has an inglorious past, murky present, and cheerless future. STL introduced allocators as a stop gap for the now antiquated segmented memory models of the 1990s. Their design was limited and in many ways wasn't even aiming at helping allocation that much. Because allocators were there, they simply continued being there, up to the point they became impossible to either uproot or make work, in spite of valiant effort spent by the community.

This talk discusses the full design of a memory allocator created from first principles. It is generic, componentized, and composable for supporting application-specific allocation patterns.

His main points against the current std::allocator are contained in this section of the video, but to summarize:

1. Allocators should not care about the type being allocated, only the size and alignment.
2. Allocators should not be responsible for storing size information about an allocation, allocation and deallocation should symmetrically (respectively) return and receive a Blk (ptr, size).
3. Rebind<U>::other is terrible (he did not go in further detail)
4. Allocators should not be stateless (since they literally give you pieces of memory, how can they be stateless?)
5. Allocators should be defined around the concept of composition; if you look at real world allocators they are all composed of small little allocators that conditionally run.

Ever since I watched that talk I have expected some kind of proposal to follow from it, since the idea seemed so sound and usable. I've had to work with std::allocator in the past and it made me understand the need for C++20 concepts for the first time when my screen screamed at me in candidate function not viable.

But nothing seems to have come from it? I wasn't around back then but it seems like STL2 was in the works, but that has since been discontinued. Has it been decided somewhere that concepts would be sufficient to at least mediate the symptoms of std::allocator (if so, where/when?) or is it a backwards-compatibility problem? Is something related to this on the roadmap for a future C++ version?

Answer 1

There is no proposal for a radical re-alteration of the allocator model. This is for basically two reasons.

The C++ container library relies on allocators working a certain way, and it would be complex in the extreme to make containers that work with both kinds of allocators. So if you want a new allocator model, you're also talking about a new set of containers, which is a huge can of worms that the committee balked at opening.

Most of the deficiencies in allocator creation and usage are pretty avoidable these days. Writing an allocator even in C++17 is not exactly a challenge. You don't need to understand the gory details of the thing; you just need to implement a couple of functions and a few member aliases. std::allocator_traits fills in most of the blanks for you.

At the end of the day, there are significant deficiencies in the C++ language and library that are more important than an allocator model that's more difficult to use than is strictly necessary.