c++ - 为什么 propagate_on_XXX_assignment 不适用于构造函数？

Question

C++11 std::allocator_traits模板用于查询 Allocator确定是否propagate_on_copy_assignment和 propagate_on_move_assignment是true .这些值会影响容器类型必须如何实现复制和移动分配。如果std::allocator_traits<Allocator>::propagate_on_move_assignment == true然后容器移动赋值运算符必须使用 RHS 容器对象中包含的分配器移动分配其内部分配器对象。

据推测，重点是我们可以实现 Allocator可以通知客户端 Container 是否为 move 的类型或 copy操作应该要求我们复制分配器内部的任何内部状态。

那么...为什么这些类型定义仅适用于赋值。为什么我们没有 propagate_on_copy_construct和 propagate_on_move_construct ？如果分配器有一些内部状态，客户端 Container 对象不应该知道它是否应该复制/移动分配器吗？

Answer 1

在作业中有两个选择:

1. 保留您现有的分配器。
2. 从 rhs 分配器复制/移动。

propagate_on_assign traits 控制赋值运算符的选择。

对于构造，选择 1(保留现有的分配器)不是一个选项。 没有现有的分配器。相反，您的选择是:

1. 从无到有构建一个分配器。
2. 从 rhs 分配器复制/移动。
3. 从其他来源复制/移动。

可以考虑选择一个:默认构造一个分配器。选择 3 非常模糊，但不同的分配器方案可能无法预测，最好为分配器设计者提供尽可能多的灵 active :可能做一些委员会从未预料到的事情。

为了满足所有三个选择，至少对于容器复制构造函数，设计了一个新的 allocator_traits“开关”:

Alloc select_on_container_copy_construction(const Alloc& rhs);

allocator_traits将返回 rhs. select_on_container_copy_construction()如果该表达式格式正确。否则它将返回 rhs .容器复制构造函数需要使用 allocator_traits<A>:: select_on_container_copy_construction(a)在复制构造期间构造 lhs 分配器时。

对于只想在复制构造期间复制其分配器的分配器设计者(选择 2)，他们无需执行任何操作。

如果分配器设计者希望在容器拷贝构造上默认构造 lhs 分配器，则只需为其分配器编写以下成员函数:

Alloc select_on_container_copy_construction() const {return Alloc{};}

如果他们为选择 3 想出一些聪明的东西，他们可能可以使用与选择 1 相同的钩子(Hook)来实现它。

因此对于复制构造，不需要 propagate_on特征为 select_on_container_copy_construction已经涵盖了所有基地。

对于移动构造，请参阅 N2982 的第 12 页底部:

Note that there is no select_on_container_move_construction() function. After some consideration, we decided that a move construction operation for containers must run in constant-time and not throw, as per issue 1166.

事实上，这篇论文和它之前的论文(它引用的)是 C++11 分配器设计背后的基本原理的良好信息来源。本文甚至引用了 allocator_propagate_on_copy_construction来自之前的一篇论文，后来演变成 select_on_container_copy_construction() .