为什么用户定义的移动构造函数会禁用隐式复制构造函数？

当我阅读 boost/shared_ptr.hpp 时，我看到了这段代码：

//  generated copy constructor, destructor are fine...

#if defined( BOOST_HAS_RVALUE_REFS )

// ... except in C++0x, move disables the implicit copy

shared_ptr( shared_ptr const & r ): px( r.px ), pn( r.pn ) // never throws
{
}

#endif

注释“生成的复制构造函数、析构函数都很好，除了在 C++11 中，移动禁用隐式复制”在这里意味着什么？我们是否应该始终自己编写复制构造函数来防止 C++11 中出现这种情况？

我赞成 ildjarn 的回答，因为我发现它既准确又幽默。 :-)

我提供替代答案是因为我假设OP可能想知道问题的标题why标准是这么说的。

背景

C++ 已经隐式生成了复制成员，因为如果没有，它就会在 1985 年胎死腹中，因为它是so与 C 不兼容。如果那样的话，我们今天就不会进行这样的对话，因为 C++ 就不会存在。

话虽这么说，隐式生成的复制成员类似于“与魔鬼打交道”。没有它们，C++ 就不可能诞生。但它们是邪恶的，因为它们在大量实例中默默地生成不正确的代码。 C++ 委员会并不傻，他们知道这一点。

C++11

既然 C++ 已经诞生，并且已经发展成为一个成功的成熟体，委员会很想说：我们不再做隐式生成的复制成员了。他们太危险了。如果您想要隐式生成的复制成员，您必须选择加入该决定（而不是选择退出）。然而，考虑到如果这样做的话现有的 C++ 代码量将会被破坏，这无异于自杀。有一个huge向后兼容性的担忧是相当合理的。

因此委员会达成了妥协的立场：如果您声明移动成员（旧版 C++ 代码无法做到这一点），那么我们将假设默认的复制成员可能会做错误的事情。选择加入（与=default）如果你想要的话。或者自己写。否则它们将被隐式删除。我们迄今为止在仅移动类型的世界中的经验表明，这种默认位置实际上是非常常见的所需位置（例如unique_ptr, ofstream, future， ETC。）。选择加入的费用实际上相当小= default.

期待

The committee would love to even say: If you've written a destructor, it is likely that the implicit copy members are incorrect, so we will delete them. This is the C++98/03 "rule of three". However even that would break lots of code. However the committee has said in C++11 that if you provide a user-declared destructor, the implicit generation of copy members is deprecated.^{1, 2} That means that this feature could be removed in a future standard. And that any day now your compiler might start issuing "deprecated warnings" in this situation (the standard can not specify warnings).

结论

因此请预先警告：C++ 经过几十年的发展和成熟。这意味着您父亲的 C++ 可能需要迁移才能处理您孩子的 C++。这是一个缓慢、渐进的过程，这样您就不会放弃并移植到另一种语言。但它is改变，即使缓慢。

¹ http://eel.is/c++draft/class.mem#class.copy.ctor-6.sentence-3

² http://eel.is/c++draft/class.mem#class.copy.assign-2.sentence-3