是否计划在未来的 C++ 版本中修订 std::allocator 接口？

Question

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

<块引用>

std::allocator 有一个不光彩的过去，阴暗的现在和令人沮丧的未来。 STL 引入了分配器作为 1990 年代现在过时的分段内存模型的止损。他们的设计是有限的，而且在很多方面甚至没有那么大的帮助分配。因为分配器在那里，所以他们只是继续在那里，直到他们变得不可能连根拔起或工作，尽管社区付出了英勇的努力。

<块引用>

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

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

1. 分配器不应该关心被分配的类型，只关心大小和对齐。
2. 分配器不应该负责存储有关分配的大小信息，分配和解除分配应该对称地（分别）返回和接收 Blk (ptr, size)。
3. Rebind<U>::other 很糟糕（他没有详细说明）
4. 分配器不应该是无状态的（因为它们确实给了你一些内存，它们怎么可能是无状态的？）
5. 分配器应该围绕组合的概念来定义；如果你看看现实世界的分配器，它们都是由有条件地运行的小分配器组成的。

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

但似乎什么也没有发生？当时我不在，但似乎 STL2 正在开发中，但此后已停止使用。是否已在某处决定概念至少足以调解 std::allocator 的症状（如果是，在哪里/何时？）还是向后兼容性问题？未来 C++ 版本的路线图是否与此相关？

Answer 1

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

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

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

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