对于分配器，为什么需要select_on_container_copy_construction而不是使复制构造函数过载？
是否存在根据我们是否要复制实际的分配器vs容器来定义两个单独的复制构造实现的实例？
答案 0 :(得分：3)
（您所指的特征实际上称为select_on_container_copy_construction。）
实际上，标准库容器 的副本构造函数已重载，并提供了分配器扩展的版本：
A a1 = f(), a2 = g(); // allocators
std::vector<int, A> v1(a1);
std::vector<int, A> v2(v1, a2); // allocator-extended copy
std::vector<int, A> v3 = v1; // regular copy, uses select_on_container_copy_construction
但是，使用重载并非始终是一种选择，通常，对分配器敏感的容器应该可以像不了解分配器选择一样容易且无缝地使用。这意味着某些决定（例如如何分配容器的副本）可能需要直接通过分配器类型而不是用户类型进行自定义。
例如，您可以想象一种情况，其中一个向量的内容全部进入一个（可能是可增长的）舞台，但是当您创建一个新向量时，您希望将其转到一个新的，独立的舞台，并且通用代码不需要了解这一点。
此库功能在实践中是否有用是一个单独的问题，但是希望这表明了为什么该零件设计有一定动机。