c++ - 我们能和复制构造函数说再见吗？

Question

复制构造函数传统上在 C++ 程序中无处不在。但是，我怀疑自 C++11 以来是否有充分的理由这样做。

即使程序逻辑不需要复制对象，复制构造函数(usu.default)通常仅用于对象重新分配。没有复制构造函数，您无法将对象存储在 std::vector 中，甚至无法从函数返回对象。

但是，从 C++11 开始，移动构造函数负责对象的重新分配。

复制构造函数的另一个用例是简单地复制对象。但是，我非常相信 .copy() 或 .clone() 方法比复制构造函数更适合该角色，因为...

1. 复制对象并不是很常见。当然，有时对象的接口(interface)必须包含“复制你自己”的方法，但只是在某些时候。在这种情况下，显式优于隐式。

2. 有时一个对象可能会公开多个不同的 .copy() 类方法，因为在不同的上下文中可能需要以不同的方式创建拷贝(例如，更浅或更深)。

3. 在某些情况下，我们希望 .copy() 方法做一些与程序逻辑相关的重要事情(增加一些计数器，或者可能为拷贝)。我不会接受任何在复制构造函数中具有非显而易见逻辑的代码。

4. 最后但同样重要的是，如果需要，.copy() 方法可以是虚拟的，从而解决 slicing 的问题。 .

---

我真正想要使用复制构造函数的唯一情况是:

• RAII 处理可复制资源(很明显)
• 旨在像内置类型一样使用的结构，例如数学 vector 或矩阵 -
  仅仅是因为它们经常被复制，而且 vec3 b = a.copy() 太冗长了。

Side note: I've considered the fact that copy constructor is needed for CAS, but CAS is needed for operator=(const T&) which I consider redundant basing on the exact same reasoning;
.copy() + operator=(T&&) = default would be preferred if you really need this.)

对我来说，这足以激励我在所有地方默认使用 T(const T&) = delete 并在需要时提供 .copy() 方法。 (也许还有一个 private T(const T&) = default 只是为了能够在没有样板的情况下编写 copy() 或 virtual copy()。 )

问:上述推理是否正确，或者我是否遗漏了逻辑对象实际需要或以某种方式受益于复制构造函数的任何充分理由？

具体来说，在 C++11 中移动构造函数完全接管了对象重新分配的责任，我是否正确？当对象需要在内存中的其他地方移动而不改变其状态时，我非正式地使用“重新分配”。

Answer 1

问题是“对象”指的是什么。

如果对象是变量引用的资源(就像在 java 或 C++ 中通过指针，使用经典的 OOP 范例)每个“变量之间的复制”都是“共享”，并且如果单一所有权强加于人，“分享”变成了“感动”。

如果 objects 是变量本身，因为每个变量都必须有自己的历史，如果你不能/不想强制破坏一个值以支持它，你就不能“移动”另一个。

考虑例如std::strings:

   std::string a="Aa";
   std::string b=a;
   ...
   b = "Bb";

您希望 a 的值发生变化，还是该代码无法编译？如果没有，则需要复制。

现在考虑一下:

   std::string a="Aa";
   std::string b=std::move(a);
   ...
   b = "Bb";

现在 a 为空，因为它的值(更好的是，包含它的动态内存)已“移动”到 b。 b 的值随后被更改，旧的 "Aa" 被丢弃。

本质上，只有在显式调用或者正确的参数是“临时的”时，move 才起作用，就像在

  a = b+c;

operator+ 返回的资源在分配后显然不需要，因此将其移动到 a，而不是将其复制到另一个 a 的保留位置和删除它更有效。

移动和复制是两个不同的东西。移动不是“复制的替代品”。这是一种更有效的方法，可以避免仅在对象不是需要 生成自身克隆的所有情况下进行复制。