相关疑难解决方法(0)

我注意到std::vector容器的交换函数具有与所有其他容器不同的 noexcept 规范。具体来说，如果表达式 std::allocator_traits<Allocator>::propagate_on_container_swap || std::allocator_traits<Allocator>::is_always_equal为 true，则该函数为 no except，但其他容器要求表达式std::allocator_traits<Allocator>::is_always_equal为 true。

既然交换函数的行为是相同的，为什么 noexcept 规范仅在std::vector容器中不同？

在容器中具有这些特征的原因是什么（https://en.cppreference.com/w/cpp/memory/allocator_traits）

propagate_on_container_copy_assignment  Alloc::propagate_on_container_copy_assignment if present, otherwise std::false_type
propagate_on_container_move_assignment  Alloc::propagate_on_container_move_assignment if present, otherwise std::false_type
propagate_on_container_swap             Alloc::propagate_on_container_swap if present, otherwise std::false_type

is_always_equal(since C++17)            Alloc::is_always_equal if present, otherwise std::is_empty<Alloc>::type

我知道容器实现在分配和交换的实现中会以一种或另一种方式表现。（并且处理这些情况是可怕的代码。）我也明白有时人们可能需要将移动容器保持在一种状态resizeble或者至少可以调用一些最后的释放，因此分配器不能无效。（我个人认为这是一个弱论点。）

但问题是， 为什么这些信息不能成为自定义分配器类型本身的正常实现和语义的一部分？

我的意思是，容器复制分配可以尝试复制分配源分配器，如果语法复制分配没有真正复制，那么，就像说你的容器没有 propagate_on_container_copy_assignment。

以同样的方式而不是使用 is_always_equal一个实际上可以使分配器分配什么也不做。

（此外，如果is_always_equal为真，则可以让operator==分配器返回std::true_type以发出信号。）

在我看来，这些特征似乎试图覆盖可以通过普通 C++ 方式提供给自定义分配器的语义。这似乎与泛型编程和当前的 C++ 哲学背道而驰。

唯一的原因，我认为这对于实现与“旧”容器的某种向后兼容性很有用。

如果我今天要编写一个新容器和/或一个新的非平凡分配器，我可以依靠分配器的语义而忘记这些特征吗？

在我看来，只要移动的分配器可以“解除分配”一个空指针状态（这意味着在这种特殊情况下主要是什么都不做），那么它应该没问题，如果resize抛出，那也很好（有效） ，这只是意味着分配器无法再访问其堆。

编辑：实际上， 我可以这样简单地编写容器吗？并将复杂性委托给自定义分配器的语义？：

templata<class Allocator>
struct my_container{
  Allocator alloc_;
  ...
  my_container& operator=(my_container const& other){ …