我们可以说再见复制构造函数吗？

Question

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

即使程序逻辑不需要复制对象，通常也仅出于对象重新分配的目的而包含复制构造函数（通常是默认值）。没有复制构造函数，您将无法将对象存储在中，甚至无法从函数返回对象。std::vector

但是，自C ++ 11起，移动构造函数一直负责对象的重新分配。

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

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

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

3. 在某些情况下，我们希望这些.copy()方法完成与程序逻辑相关的重要工作（增加一些计数器，或者为副本生成一个新的唯一名称）。我不会接受任何在复制构造函数中具有非显而易见逻辑的代码。

4. 最后但并非最不重要的一点是，.copy()如果需要，一种方法可以是虚拟的，从而可以解决切片问题。

---

我实际想要使用复制构造函数的唯一情况是：

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

旁注：我已经考虑过CAS需要复制构造函数这一事实，但出于operator=(const T&)完全相同的推理，我认为CAS是必需的；如果您确实需要此，则首选
.copy()+ operator=(T&&) = default。）

对我而言，这足以激励T(const T&) = delete默认情况下在任何地方使用并.copy()在需要时提供一种方法。（也许也private T(const T&) = default只是能够写copy()或virtual copy()没有样板。）

问：以上推理是否正确，或者我是否缺少逻辑对象实际需要或从复制构造函数中以某种方式受益的任何充分理由？

具体来说，我是否正确，因为移动构造函数完全取代了C ++ 11中的对象重新分配的职责？当对象需要在不更改其状态的情况下在内存中的其他位置移动时，我会在所有情况下非正式地使用“重新分配”。

Answer 1

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

如果对象是变量引用的资源（例如在Java或C ++中通过指针，使用经典的OOP范式），则每个“变量之间的副本”都是“共享”，并且如果施加单一所有权，则“共享”将变为“移动”。 。

如果对象本身就是变量，则由于每个变量都必须具有自己的历史记录，因此，如果您不能/不想强加破坏另一个值，就不能“移动”。

例如，Cosider 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留空，因为a的值（最好是包含它的动态内存）已“移动”到b。b然后，将的值进行舍弃，并将旧的"Aa"舍弃。

本质上，仅当显式调用或正确的参数为“临时”（例如，

  a = b+c;

在operator+分配之后显然不需要通过归还来保留资源的情况，因此将其移至a，而不是将其复制到另一个a的保留位置并删除它会更有效。

移动和复制是两件事。移动不是“替换副本”。这是一种仅在不需要对象生成其自身克隆的所有情况下才避免复制的更有效方法。