为什么Allocator::reference会被淘汰？

Question

所以我在研究std::vector的规范时，注意到reference类型定义从C++03中的Allocator::reference变成了C++11中的value_type&，我很惊讶，所以我开始更深入地研究。

在C++03§20.1.5 lib.allocator.requirements中，有一个表32，其中X::reference定义为T&，X::const_reference定义为T const&。

然而，在C++11§17.6.3.5 allocator.requirements中，表28中缺少reference和const_reference。

接下来，我们在C++11中添加了§20.6.8 std::allocator_traits，其中不包括reference。但是第20.6.9节std::allocator有。

最后，有23.2.1节container.requirements.general，它将X::reference定义为“T的左值”，将X::const_reference定义为“T的常量值”。

所以，我在谷歌上搜索并找到了这篇论文(1，2)，它建议从分配器需求中删除reference，但它并没有提到它背后的任何理由。但也有一个LWG issue反对这一改变。

此外，我还发现了the interview with Alexander Stepanov，他在其中谈到了reference如何封装特定于机器的内存布局和Herb Sutter's post，他在其中谈到了指向容器元素的指针、容器要求以及std::vector<bool>如何不是容器。

那么，你对这一切有什么看法？reference有用吗?它有没有达到它的目的？“花哨”的引用如何与标准相适应？这是一个彻底消除它们，制定更严格的容器要求并弃用std::vector<bool>的大胆举措吗？

Answer 1

在the interview with Alexander Stepanov中，他提到，在向标准库添加STL的提案中，他被要求从内存模型中创建一个抽象。这样，分配器就诞生了。在LWG issue中，有一个自定义分配器的reference被定义为T __far&的实现示例。

但是，由于未知的原因，因为我没有太多的时间来搜索，C++03标准在§20.1.5 p4中有以下文本：

本国际标准中描述的容器的

实现允许假定它们的分配器模板参数满足表32中以外的以下两个额外要求。

-给定分配器类型的所有实例都要求是可互换的，并且总是相互比较相等。

- typedef成员指针、const_pointer、size_type和difference_type分别需要为T*、T const*、size_t和ptrdiff_t。

这有效地削弱了自定义内存模型分配器与标准容器互操作的能力。

在我搜索所有提到“分配器”这个词的C++11之前的论文时，我发现了一个主要的共识，那就是从标准中删除这些词。最后，this paper建议通过以下评论删除它们：

黄鼠狼的话不见了。举杯干杯。

胜利？我们终于可以疯狂地使用我们的内存模型了吗？没那么多。此外，同一篇论文还建议将reference从分配器需求中删除。看起来像是被选进了标准报。

我前面提到的LWG issue反对这一更改，但它以以下语句结束：

没有做出改变的共识

所以看起来分配器的最初目的在今天已经不那么重要了。下面是Wikipedia要说的话：

分配器的当前用途是让程序员控制容器内的内存分配，而不是调整底层硬件的地址模型。事实上，修订后的标准消除了分配器表示C++地址模型扩展的能力，正式地(有意地)消除了它们最初的用途。

最后，Container::reference与分配器无关。创建它是为了允许代理集合which are not actually containers。所以它会留在这里。顺便说一句，它看起来像是另一个例子，说明了标准中的最终词语是如何违背初衷的。

Answer 2

因为该嵌套的typedef是多余的。斯科特·梅耶斯的Effective STL，第49页：

标准明确地允许库实现者假设每个分配器的指针

是T*的同义词，并且每个分配器的引用类型定义f与T&

相同

Answer 3

http://en.wikipedia.org/wiki/Allocator_(C%2B%2B)

“它们最初的目的是为了使库更加灵活和独立于底层内存模型，允许程序员利用库中的自定义指针和引用类型。然而，在将C++采用到C++标准中的过程中，STL标准化委员会意识到完全抽象内存模型将导致不可接受的性能损失。为了弥补这一点，对分配器的要求变得更加严格。结果，由分配器提供的定制级别比Stepanov最初设想的更有限。”

最初，它们被设计为抽象内存本身，允许一个人通过和互联网连接在另一台机器上分配内存，并使用指针/引用来回复制数据，以跟踪活动的内容。类似地，可以用纯C++编写类似于Java的GC。这个抽象看起来是个很棒的想法！

然而，这导致了性能损失，这在当时被认为是不可接受的。而且，如果你仔细想想，在代码中工作几乎是不可能的。每个分配器都必须放入template<class allocator> void func(allocator::reference)中，这是一个不可推断的上下文，因此您必须在函数调用(func<std::allocator<std::string>::const_reference>(username))中显式编写分配器，没有人会这样做，这会使GC不能正常工作。现在，分配器只是抽象内存分配/释放。