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.
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? 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?
Source: Windows Questions C++