为什么需要select_on_container_copy_construction

Why is select_on_container_copy_construction needed?

本文关键字:container copy construction on 为什么 select      更新时间:2023-10-16

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

当我们想根据是否复制实际的分配器与容器来定义两个独立的复制构造实现时,是否存在实例?

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

然而,使用重载并不总是一种选择,而且通常情况下,具有分配器意识的容器应该可以像您不知道分配器的选择一样轻松无缝地使用。这意味着某些决策,例如如何分配容器的副本,可能需要直接通过分配器类型进行自定义,而不是通过用户的类型进行自定义。

例如,你可以想象一种情况,一个向量的内容都进入一个(可能是可生长的)竞技场,但当你制作一个新向量时,你希望它进入一个新的、独立的竞技场,通用代码不需要知道这一点。

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