为什么需要 select_on_container_copy_construction？答案

【问题标题】：Why is select_on_container_copy_construction needed?为什么需要 select_on_container_copy_construction？
【发布时间】：2019-06-09 00:00:01
【问题描述】：

对于分配器，为什么需要select_on_container_copy_construction 而不是仅仅重载复制构造函数？

是否存在我们想要定义两个单独的复制构造实现的情况，具体取决于我们是否复制实际的分配器与容器？

【问题讨论】：

标签： c++ c++11 memory-management c++17

【解决方案1】：

（您所指的特征实际上称为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

但是，使用重载并不总是一种选择，通常，分配器感知容器应该可以像您不知道分配器选择一样轻松无缝地使用。这意味着某些决定，例如如何分配容器的副本，可能需要直接通过分配器类型进行定制，而不是通过用户的类型。

例如，您可以想象这样一种情况，其中一个向量的内容全部进入一个（可能是可增长的）竞技场，但是当您制作一个新向量时，您希望它进入一个新的、单独的竞技场，并且通用代码不需要知道这一点。

这个库功能在实践中是否有用是一个单独的问题，但希望这能说明为什么这个部件设计有一些动机。

【讨论】：

我读了几遍才最终将它解析在一起。有兴趣查看任何真实世界的示例（如果有的话）。谢谢
@JosephFranciscus：我不知道任何“普通”分配器，select_on_container_copy_construction 除了立即返回当前分配器的副本外，不会做任何事情，但是我在答案可能是一个合理的设计。还要考虑 trait 可能会返回一个副本并且还执行一些其他操作，例如通知一些全局内存管理器已经发生了复制等。
@KerrekSB std::pmr::polymorphic_allocator 使用 select_on_container_copy_construction 在复制时使用默认内存资源生成 pmr 分配器，而不是传播现有内存资源。