是的，我认为为这样的类提供一个移动构造函数会很好，但请记住:

It's only an optimization. Implementing only one or two of the copy constructor, assignment operator or destructor will probably lead to bugs, while not having a move constructor will just potentially reduce performance. Move constructor cannot always be applied without modifications. Some classes always have their pointers allocated, and thus such classes always delete their pointers in the destructor. In these cases you'll need to add extra checks to say whether their pointers are allocated or have been moved away (are now null).

简单来说，记住这一点。

0法则:

类既没有自定义析构函数、复制/移动构造函数，也没有复制/移动赋值操作符。

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

析构函数，复制构造函数，复制赋值

规则5: 如果你实现了一个自定义的move构造函数或move赋值操作符，你需要定义所有5个。需要移动语义。

析构函数，复制构造函数，复制赋值，移动构造函数，移动赋值

四分之一法则: 与第5条规则相同，但使用了复制和交换习惯用语。通过包含swap方法，复制赋值和移动赋值合并为一个赋值操作符。

析构函数，复制构造函数，移动构造函数，赋值，交换(一半)

引用:

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

是的，我认为为这样的类提供一个移动构造函数会很好，但请记住:

It's only an optimization. Implementing only one or two of the copy constructor, assignment operator or destructor will probably lead to bugs, while not having a move constructor will just potentially reduce performance. Move constructor cannot always be applied without modifications. Some classes always have their pointers allocated, and thus such classes always delete their pointers in the destructor. In these cases you'll need to add extra checks to say whether their pointers are allocated or have been moved away (are now null).

真不敢相信没人跟这事有关。

文章基本上主张“零规则”。 我不适合引用整篇文章，但我认为这是主要观点:

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

在我看来，这一点很重要:

标准中包括常见的“包中的所有权”类 库:std::unique_ptr和std::shared_ptr。通过使用 自定义删除器对象，两者都已变得足够灵活，可以进行管理 几乎任何种类的资源。

我想说，三原则变成了三、四、五原则:

Each class should explicitly define exactly one of the following set of special member functions: None Destructor, copy constructor, copy assignment operator In addition, each class that explicitly defines a destructor may explicitly define a move constructor and/or a move assignment operator. Usually, one of the following sets of special member functions is sensible: None (for many simple classes where the implicitly generated special member functions are correct and fast) Destructor, copy constructor, copy assignment operator (in this case the class will not be movable) Destructor, move constructor, move assignment operator (in this case the class will not be copyable, useful for resource-managing classes where the underlying resource is not copyable) Destructor, copy constructor, copy assignment operator, move constructor (because of copy elision, there is no overhead if the copy assignment operator takes its argument by value) Destructor, copy constructor, copy assignment operator, move constructor, move assignment operator

注意:

That move constructor and move assignment operator won't be generated for a class that explicitly declares any of the other special member functions (like destructor or copy-constructor or move-assignment operator). That copy constructor and copy assignment operator won't be generated for a class that explicitly declares a move constructor or move assignment operator. And that a class with an explicitly declared destructor and implicitly defined copy constructor or implicitly defined copy assignment operator is considered deprecated.

特别是以下完全有效的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
};

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

In contrast to the Rule of the Big Three, where failing to adhere to the rule can cause serious damage, not explicitly declaring the move constructor and move assignment operator is generally fine but often suboptimal with respect to efficiency. As mentioned above, move constructor and move assignment operators are only generated if there is no explicitly declared copy constructor, copy assignment operator or destructor. This is not symmetric to the traditional C++03 behavior with respect to auto-generation of copy constructor and copy assignment operator, but is much safer. So the possibility to define move constructors and move assignment operators is very useful and creates new possibilities (purely movable classes), but classes that adhere to the C++03 Rule of the Big Three will still be fine.

For resource-managing classes you can define the copy constructor and copy assignment operator as deleted (which counts as definition) if the underlying resource cannot be copied. Often you still want move constructor and move assignment operator. Copy and move assignment operators will often be implemented using swap, as in C++03. Talking about swap; if we already have a move-constructor and move-assignment operator, specializing std::swap will become unimportant, because the generic std::swap uses the move-constructor and move-assignment operator if available (and that should be fast enough).

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

Basically, it's like this: If you don't declare any move operations, you should respect the rule of three. If you declare a move operation, there is no harm in "violating" the rule of three as the generation of compiler-generated operations has gotten very restrictive. Even if you don't declare move operations and violate the rule of three, a C++0x compiler is expected to give you a warning in case one special function was user-declared and other special functions have been auto-generated due to a now deprecated "C++03 compatibility rule".

I think it's safe to say that this rule becomes a little less significant. The real problem in C++03 is that implementing different copy semantics required you to user-declare all related special functions so that none of them is compiler-generated (which would otherwise do the wrong thing). But C++0x changes the rules about special member function generation. If the user declares just one of these functions to change the copy semantics it'll prevent the compiler from auto-generating the remaining special functions. This is good because a missing declaration turns a runtime error into a compilation error now (or at least a warning). As a C++03 compatibility measure some operations are still generated but this generation is deemed deprecated and should at least produce a warning in C++0x mode.

由于编译器生成的特殊函数的限制规则和c++ 03的兼容性，3的规则仍然是3的规则。

下面是一些适用于最新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的兼容性，三原则在这里仍然适用。