是否计划为未来的 C++ 版本修订 std::allocator 接口？答案

【问题标题】：Is a revision of the std::allocator interface planned for future C++ versions?是否计划为未来的 C++ 版本修订 std::allocator 接口？
【发布时间】：2021-06-22 06:03:12
【问题描述】：

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

std::allocator 有着不光彩的过去、阴暗的现在和无趣的未来。 STL 引入分配器作为 1990 年代现已过时的分段内存模型的权宜之计。他们的设计是有限的，并且在很多方面甚至都没有旨在帮助分配那么多。因为分配者在那里，他们只是继续在那里，直到他们变得无法根除或工作，尽管社区付出了英勇的努力。

本演讲讨论了根据第一原则创建的内存分配器的完整设计。它是通用的、组件化的和可组合的，用于支持特定于应用程序的分配模式。

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

分配器不应该关心被分配的类型，只关心大小和对齐方式。
分配器不应负责存储有关分配的大小信息，分配和解除分配应对称（分别）返回并接收Blk（ptr，大小）。
Rebind<U>::other 太可怕了（他没有说得更详细）
分配器不应该是无状态的（因为它们确实给了你一些内存，它们怎么可能是无状态的？）
分配器应该围绕组合的概念来定义；如果您查看现实世界的分配器，它们都是由有条件运行的小型分配器组成的。

自从我看了那场演讲后，我就一直期待着能从中得到一些建议，因为这个想法看起来非常合理和实用。过去我不得不使用 std::allocator，当我的屏幕在候选函数不可行中向我尖叫时，它让我第一次理解了对 C++20 概念的需求。

但似乎没有任何东西来自它？那时我不在，但似乎 STL2 正在开发中，但后来已经停产了。是否已在某处确定概念足以至少调解 std::allocator 的症状（如果是，在哪里/何时？）还是向后兼容问题？未来 C++ 版本的路线图是否与此相关？

【问题讨论】：

您能否详细说明实际上与分配无关以及您希望它是什么样的？
将它包含在 STL 中的最初原因显然是为了处理近/远指针的问题：谈话的this section 强调了 std::allocator 的主要问题，其余的它概述了一个新的设计。他基本上建议使用小型可组合的预定义分配器，例如“segrator”、“stackallocator”、“nullallocator”、“fallbackallocator”，并使用组合来为某个应用程序构建一个复杂的自定义分配器。
其实this section 稍晚一点总结的比较好。
我不想看冗长的演示文稿。能否总结一下当前分配器接口存在的问题？
@SergeBallesta 我用简短的摘要更新了这个问题。不过，我确实建议您观看它，对我来说，它非常有见地！

标签： c++ c++20 allocator c++-concepts c++23

【解决方案1】：

没有提议彻底改变分配器模型。这主要有两个原因。

C++ 容器库依赖于以某种方式工作的分配器，要让容器同时使用这两种分配器会非常复杂。因此，如果您想要一个新的分配器模型，那么您也是在谈论一组新的容器，即委员会不愿打开的巨大罐蠕虫。

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

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

【讨论】：

委员会中关于它的讨论是否记录在某个地方？
@AdriaanJacobs：从来没有关于这个主题的提案，所以委员会没有什么可以讨论的。我正在解释为什么这样的事情从未被提出并且可能不会被接受。
我想因为你说委员会不愿打开这个巨大的蠕虫罐，这是指你读过的东西。另外，你不认为 Andrei 的提议的一个子集可以在当前的 std::allocator 接口下实现吗？预定义几个满足分配器要求并且像 Andrei 建议的那样模块化的类？

【解决方案2】：

我们已经在分配器之上构建了std::pmr，可以解决所有列出的问题。

【讨论】：