c++ - 是否计划为 future 的 C++ 版本修订 std::allocator 接口(interface)？

Question

在a talk from 2015 Andrei Alexandrescu 概述了 std::allocator 接口(interface)的一些暴行，简短地强调了它实际上与分配无关，并提出了一种不同的思考这些分配器的方式，这将使它们更加可用和模块化。或者，引用描述:

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.

他反对当前 std::allocator 的主要观点包含在 this section 中。的视频，但总结一下:

1. 分配器不应该关心被分配的类型，只关心大小和对齐方式。
2. 分配器不应负责存储有关分配的大小信息，分配和释放应对称(分别)返回并接收 Blk (指针，大小)。
3. Rebind<U>::other太可怕了(他没有说得更详细)
4. 分配器不应该是无状态的(因为它们确实为您提供了内存片段，它们怎么可能是无状态的呢？)
5. 应围绕组合概念定义分配器；如果你看看现实世界的分配器，它们都是由有条件地运行的小分配器组成的。

自从我看了那次演讲后，我就期待着能从中得到某种建议，因为这个想法似乎很合理而且很有用。过去我不得不使用 std::allocator，当我的屏幕显示 候选函数不可行 时，它让我第一次理解了 C++20 概念的必要性。

但是好像什么都没有？那时我不在身边，但似乎 STL2 正在开发中，但后来已经停产了。是否已在某处决定概念足以至少调解 std::allocator 的症状(如果是，在何处/何时？)还是向后兼容问题？ future C++ 版本的路线图是否与此相关？

Answer 1

没有提议彻底改变分配器模型。这基本上有两个原因。

C++ 容器库依赖于以特定方式工作的分配器，而制作同时适用于这两种分配器的容器将极其复杂。因此，如果您想要一个新的分配器模型，您也在谈论一组新的容器，这是一个巨大的蠕虫 jar 头，委员会在开放时犹豫不决。

如今，分配器创建和使用中的大部分缺陷都可以避免。即使在 C++17 中编写分配器也不是什么挑战。你不需要了解这件事的血淋淋的细节；您只需要实现几个函数和几个成员别名。 std::allocator_traits 为您填补了大部分空白。

归根结底，C++ 语言和库中存在重大缺陷，这些缺陷比分配器模型更重要，分配器模型比严格必要的更难使用。