首页 > 解决方案 > 为什么需要 select_on_container_copy_construction?

问题描述

对于分配器,为什么select_on_container_copy_construction需要与仅重载复制构造函数相反?

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

标签: c++c++11memory-managementc++17

解决方案


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

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

例如,您可以想象一个向量的内容都进入一个(可能是可增长的)竞技场的情况,但是当您创建一个新向量时,您希望它进入一个新的、单独的竞技场,并且通用代码应该不需要知道这一点。

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


推荐阅读