342

因此,在观看了关于右值引用的精彩讲座后,我认为每个类都会受益于这样的“移动构造函数”、template<class T> MyClass(T&& other) 编辑,当然还有“移动赋值运算符”,template<class T> MyClass& operator=(T&& other)正如 Philipp 在他的回答中指出的那样,如果它是动态分配的成员,或通常存储指针。就像如果前面提到的要点适用,你应该有一个复制ctor、赋值运算符和析构函数。想法?

4

9 回答 9

330

我会说三法则变成三、四、五法则:

每个类都应明确定义以下一组特殊成员函数之一:

  • 没有任何
  • 析构函数、复制构造函数、复制赋值运算符

此外,显式定义析构函数的每个类都可以显式定义移动构造函数和/或移动赋值运算符。

通常,以下一组特殊成员函数是合理的:

  • 无(对于隐式生成的特殊成员函数正确且快速的许多简单类)
  • 析构函数、复制构造函数、复制赋值运算符(在这种情况下,类将不可移动)
  • 析构函数、移动构造函数、移动赋值运算符(在这种情况下,类将不可复制,对于基础资源不可复制的资源管理类很有用)
  • 析构函数、复制构造函数、复制赋值运算符、移动构造函数(由于复制省略,如果复制赋值运算符按值获取其参数,则没有开销)
  • 析构函数、复制构造函数、复制赋值运算符、移动构造函数、移动赋值运算符

笔记:

  • 对于显式声明任何其他特殊成员函数(如析构函数或复制构造函数或移动赋值运算符)的类,不会生成移动构造函数和移动赋值运算符。
  • 不会为显式声明移动构造函数或移动赋值运算符的类生成复制构造函数和复制赋值运算符。
  • 并且具有显式声明的析构函数和隐式定义的复制构造函数或隐式定义的复制赋值运算符的类被视为已弃用。

特别是,以下完全有效的 C++03 多态基类:

class C {
  virtual ~C() { }   // allow subtype polymorphism
};

应改写如下:

class C {
  C(const C&) = default;               // Copy constructor
  C(C&&) = default;                    // Move constructor
  C& operator=(const C&) = default;  // Copy assignment operator
  C& operator=(C&&) = default;       // Move assignment operator
  virtual ~C() { }                     // Destructor
};

有点烦人,但可能比替代方案更好(在这种情况下,自动生成用于复制的特殊成员函数,没有移动的可能性)。

与不遵守规则会导致严重损害的三巨头规则相反,不明确声明移动构造函数和移动赋值运算符通常很好,但在效率方面往往不是最优的。如上所述,移动构造函数和移动赋值运算符只有在没有显式声明的复制构造函数、复制赋值运算符或析构函数时才会生成。这在复制构造函数和复制赋值运算符的自动生成方面与传统的 C++03 行为不对称,但更安全。因此,定义移动构造函数和移动赋值运算符的可能性非常有用,并创造了新的可能性(纯可移动的类),但遵守 C++03 三巨头规则的类仍然可以。

对于资源管理类,如果无法复制基础资源,您可以将复制构造函数和复制赋值运算符定义为已删除(视为定义)。通常您仍然需要移动构造函数和移动赋值运算符。复制和移动赋值运算符通常使用 来实现swap,如在 C++03 中。谈论swap;如果我们已经有一个移动构造函数和移动赋值运算符,那么std::swap化将变得不重要,因为泛型std::swap使用移动构造函数和移动赋值运算符(如果可用的话)(这应该足够快)。

不用于资源管理(即没有非空析构函数)或子类型多态性(即没有虚拟析构函数)的类不应声明五个特殊成员函数中的任何一个;它们都将自动生成,并且行为正确且快速。

于 2011-01-24T14:10:43.220 回答
72

我不敢相信没有人与有关。

基本上文章主张“零规则”。我不适合引用整篇文章,但我相信这是要点:

具有自定义析构函数、复制/移动构造函数或复制/移动赋值运算符的类应该专门处理所有权。其他类不应具有自定义析构函数、复制/移动构造函数或复制/移动赋值运算符。

恕我直言,这一点也很重要:

标准库中包含常见的“包中所有权”类:std::unique_ptrstd::shared_ptr. 通过使用自定义删除器对象,两者都变得足够灵活,可以管理几乎任何类型的资源。

于 2012-12-19T11:30:12.553 回答
20

我不这么认为,法则是一个经验法则,它指出实现以下其中之一但不是全部的类可能是错误的。

  1. 复制构造函数
  2. 赋值运算符
  3. 析构函数

但是,省略移动构造函数或移动赋值运算符并不意味着存在错误。这可能是优化时错失的机会(在大多数情况下),或者移动语义与此类无关,但这不是错误。

虽然在相关时定义移动构造函数可能是最佳实践,但这不是强制性的。在许多情况下,移动构造函数与类(例如)无关,std::complex并且所有在 C++03 中行为正确的类将继续在 C++0x 中正确行为,即使它们没有定义移动构造函数.

于 2011-01-24T14:56:36.483 回答
14

是的,我认为为此类类提供移动构造函数会很好,但请记住:

  • 这只是一个优化。

    只实现一个或两个复制构造函数、赋值运算符或析构函数可能会导致错误,而没有移动构造函数只会降低性能。

  • 移动构造函数不能总是在不修改的情况下应用。

    一些类总是分配它们的指针,因此这些类总是在析构函数中删除它们的指针。在这些情况下,您需要添加额外的检查来说明它们的指针是否已分配或已被移走(现在为空)。

于 2011-01-24T14:00:28.463 回答
8

以下是自 2011 年 1 月 24 日以来有关当前状态和相关发展的简短更新。

根据 C++11 标准(见附件 D 的 [depr.impldec]):

如果类具有用户声明的复制赋值运算符或用户声明的析构函数,则不推荐使用复制构造函数的隐式声明。如果类具有用户声明的复制构造函数或用户声明的析构函数,则不推荐使用复制赋值运算符的隐式声明。

实际上,有人提议废除已弃用的行为,为 C++14 提供真正的“五规则”,而不是传统的“三规则”。2013 年,EWG 投票反对在 C++2014 中实施的提案。对该提案做出决定的主要理由与对破坏现有代码的普遍担忧有关。

最近,再次提出修改 C++11 的措辞,以实现非正式的五规则,即

如果这些函数中的任何一个是用户提供的,则编译器不会生成任何复制函数、移动函数或析构函数。

如果得到 EWG 的批准,“规则”很可能会被 C++17 采用。

于 2015-01-11T19:17:23.650 回答
4

基本上是这样的:如果你不声明任何移动操作,你应该尊重三规则。如果您声明一个移动操作,那么“违反”三规则并没有什么坏处,因为编译器生成的操作的生成变得非常严格。即使您没有声明移动操作并违反了三规则,C++0x 编译器也会在用户声明一个特殊函数并且由于现在已弃用“C++03 兼容性规则”。

我认为可以肯定地说,这条规则变得不那么重要了。C++03 中的真正问题是实现不同的复制语义需要用户声明所有相关的特殊函数,以便它们都不是编译器生成的(否则会做错事)。但是 C++0x 改变了特殊成员函数生成的规则。如果用户只声明其中一个函数来更改复制语义,它将阻止编译器自动生成剩余的特殊函数。这很好,因为缺少声明现在会将运行时错误变成编译错误(或至少是警告)。作为 C++03 兼容性措施,仍然会生成一些操作,但这一代被视为已弃用,并且至少应在 C++0x 模式下产生警告。

由于关于编译器生成的特殊函数和 C++03 兼容性的相当严格的规则,三规则仍然是三规则。

以下是一些适用于最新 C++0x 规则的示例:

template<class T>
class unique_ptr
{
   T* ptr;
public:
   explicit unique_ptr(T* p=0) : ptr(p) {}
   ~unique_ptr();
   unique_ptr(unique_ptr&&);
   unique_ptr& operator=(unique_ptr&&);
};

在上面的示例中,不需要将任何其他特殊功能声明为已删除。由于限制性规则,它们根本不会生成。用户声明的移动操作的存在会禁用编译器生成的复制操作。但在这样的情况下:

template<class T>
class scoped_ptr
{
   T* ptr;
public:
   explicit scoped_ptr(T* p=0) : ptr(p) {}
   ~scoped_ptr();
};

现在预计 C++0x 编译器会针对可能由编译器生成的复制操作发出警告,这些操作可能会做错事。在这里,三件事的规则应该得到尊重。在这种情况下发出警告是完全合适的,它让用户有机会处理错误。我们可以通过删除函数来解决这个问题:

template<class T>
class scoped_ptr
{
   T* ptr;
public:
   explicit scoped_ptr(T* p=0) : ptr(p) {}
   ~scoped_ptr();
   scoped_ptr(scoped_ptr const&) = delete;
   scoped_ptr& operator=(scoped_ptr const&) = delete;
};

因此,仅仅因为 C++03 兼容性,三的规则在这里仍然适用。

于 2011-01-24T19:55:52.517 回答
3

我们不能说 3 规则现在变成了 4 规则(或 5 规则)而不破坏所有执行 3 规则并且不实现任何形式的移动语义的现有代码。

3规则意味着如果你实施一个,你必须实施所有3个。

也不知道会有任何自动生成的移动。“规则 3”的目的是因为它们自动存在,如果你实现一个,很可能其他两个的默认实现是错误的。

于 2011-01-24T14:07:37.290 回答
2

在一般情况下,是的,三的规则变成了五的规则,并添加了移动赋值运算符和移动构造函数。但是,并非所有类都是可复制和可移动的,有些只是可移动的,有些只是可复制的。

于 2011-01-24T14:16:09.290 回答
0

简单来说,只要记住这一点。

0 规则

Classes have neither custom destructors, copy/move constructors or copy/move assignment operators.

规则 3:如果您实现了其中任何一个的自定义版本,那么您就实现了所有这些。

Destructor, Copy constructor, copy assignment

5 规则:如果您实现自定义移动构造函数或移动赋值运算符,则需要定义所有 5 个。需要移动语义。

Destructor, Copy constructor, copy assignment, move constructor, move assignment

四个半规则:与规则 5 相同,但具有复制和交换习语。通过包含交换方法,复制赋值和移动赋值合并为一个赋值运算符。

Destructor, Copy constructor, move constructor, assignment, swap (the half part)

参考资料

https://www.linkedin.com/learning/c-plus-plus-advanced-topics/rule-of-five?u=67551194 https://en.cppreference.com/w/cpp/language/rule_of_three

于 2021-06-21T06:19:09.540 回答