c++ - move 赋值运算符和 `if (this != &rhs)`

Question

在类的赋值运算符中，你通常需要检查被赋值的对象是否是调用对象，这样你就不会搞砸了:

Class& Class::operator=(const Class& rhs) {
    if (this != &rhs) {
        // do the assignment
    }

    return *this;
}

move 赋值运算符是否需要相同的东西？有没有出现过 this == &rhs会是真的吗？

? Class::operator=(Class&& rhs) {
    ?
}

Answer 1

哇，这里有很多东西要清理……

一、Copy and Swap并不总是实现复制分配的正确方法。几乎可以肯定在 dumb_array 的情况下，这是次优解。

Copy and Swap的使用适用于 dumb_array是将最昂贵的操作与最完整的功能放在底层的经典示例。它非常适合想要最完整功能并愿意支付性能损失的客户。他们得到的正是他们想要的。

但对于不需要最完整功能而是寻求最高性能的客户来说，这是灾难性的。为他们dumb_array只是他们必须重写的另一个软件，因为它太慢了。有过 dumb_array设计不同，它可以让两个客户都满意，而不会对任何一个客户做出妥协。

满足两个客户的关键是在最低级别构建最快的操作，然后在其上添加 API，以更高的成本获得更完整的功能。即您需要强大的异常保证，很好，您为此付费。你不需要吗？这是一个更快的解决方案。

让我们具体一点:这是 dumb_array 的快速、基本异常保证复制赋值运算符:

dumb_array& operator=(const dumb_array& other)
{
    if (this != &other)
    {
        if (mSize != other.mSize)
        {
            delete [] mArray;
            mArray = nullptr;
            mArray = other.mSize ? new int[other.mSize] : nullptr;
            mSize = other.mSize;
        }
        std::copy(other.mArray, other.mArray + mSize, mArray);
    }
    return *this;
}

说明:

您可以在现代硬件上做的更昂贵的事情之一是访问堆。您可以做的任何事情来避免访问堆，都是值得的时间和精力。 dumb_array的客户可能希望经常分配相同大小的数组。当他们这样做时，您需要做的就是 memcpy (隐藏在 std::copy 下)。您不想分配相同大小的新数组，然后释放相同大小的旧数组!

现在对于真正想要强大异常安全的客户:

template <class C>
C&
strong_assign(C& lhs, C rhs)
{
    swap(lhs, rhs);
    return lhs;
}

或者，如果您想利用 C++11 中的 move 赋值，应该是:

template <class C>
C&
strong_assign(C& lhs, C rhs)
{
    lhs = std::move(rhs);
    return lhs;
}

如 dumb_array的客户看重速度，他们应该调用 operator= .如果他们需要强大的异常安全性，他们可以调用通用算法，这些算法将适用于各种对象，并且只需要实现一次。

现在回到最初的问题(此时有一个 o 型):

Class&
Class::operator=(Class&& rhs)
{
    if (this == &rhs)  // is this check needed?
    {
       // ...
    }
    return *this;
}

这实际上是一个有争议的问题。有些人会说是的，绝对的，有些人会说不。

我个人的意见是不，你不需要这张支票。

理由:

当一个对象绑定(bind)到一个右值引用时，它是两件事之一:

一个临时的。

调用者希望您相信的对象是临时对象。

如果你有一个对一个实际临时对象的引用，那么根据定义，你有一个对该对象的唯一引用。它不可能被整个程序中的任何其他地方引用。即 this == &temporary 不可能 .

现在，如果您的客户对您撒谎并 promise 您会得到一个临时的，而您却没有，那么客户有责任确保您不必关心。如果您想非常小心，我相信这将是一个更好的实现:

Class&
Class::operator=(Class&& other)
{
    assert(this != &other);
    // ...
    return *this;
}

即如果您 是 传递了一个自我引用，这是客户端的一个错误，应该修复。

为了完整起见，这里是 dumb_array 的 move 赋值运算符:

dumb_array& operator=(dumb_array&& other)
{
    assert(this != &other);
    delete [] mArray;
    mSize = other.mSize;
    mArray = other.mArray;
    other.mSize = 0;
    other.mArray = nullptr;
    return *this;
}

在 move 分配的典型用例中， *this将是一个 move 的对象，所以 delete [] mArray;应该是无操作。实现尽可能快地在 nullptr 上进行删除是至关重要的。

警告:

有些人会争辩说 swap(x, x)是一个好主意，或者只是一个必要的邪恶。并且，如果交换进入默认交换，则可能导致自 move 分配。

我不同意 swap(x, x)是 曾经一个好主意。如果在我自己的代码中发现，我会认为它是一个性能错误并修复它。但如果您想允许它，请意识到 swap(x, x)仅对 move 的值进行 self-move-assignemnet。而在我们的 dumb_array例如，如果我们简单地省略断言或将其限制为 move 的情况，这将是完全无害的:

dumb_array& operator=(dumb_array&& other)
{
    assert(this != &other || mSize == 0);
    delete [] mArray;
    mSize = other.mSize;
    mArray = other.mArray;
    other.mSize = 0;
    other.mArray = nullptr;
    return *this;
}

如果您自行分配两个搬家(空) dumb_array的，除了在程序中插入无用的指令外，您不会做任何不正确的事情。可以对绝大多数对象进行相同的观察。

<更新 >

我对这个问题进行了更多思考，并稍微改变了我的立场。我现在认为赋值应该容忍自赋值，但是复制赋值和 move 赋值的后置条件是不同的:

对于拷贝分配:

x = y;

应该有一个后置条件，即 y 的值不应更改。当 &x == &y那么这个后置条件转化为:自复制赋值应该对 x的值没有影响。 .

对于 move 分配:

x = std::move(y);

应该有一个后置条件 y具有有效但未指定的状态。当 &x == &y那么这个后置条件转化为: x具有有效但未指定的状态。即自我 move 分配不一定是空操作。但它不应该崩溃。此后置条件与允许 swap(x, x) 一致只是工作:

template <class T>
void
swap(T& x, T& y)
{
    // assume &x == &y
    T tmp(std::move(x));
    // x and y now have a valid but unspecified state
    x = std::move(y);
    // x and y still have a valid but unspecified state
    y = std::move(tmp);
    // x and y have the value of tmp, which is the value they had on entry
}

以上作品，只要 x = std::move(x)不会崩溃。可以离开 x处于任何有效但未指定的状态。

我看到了三种为 dumb_array 编写 move 赋值运算符的方法实现这一目标:

dumb_array& operator=(dumb_array&& other)
{
    delete [] mArray;
    // set *this to a valid state before continuing
    mSize = 0;
    mArray = nullptr;
    // *this is now in a valid state, continue with move assignment
    mSize = other.mSize;
    mArray = other.mArray;
    other.mSize = 0;
    other.mArray = nullptr;
    return *this;
}

上面的实现允许自赋值，但是 *this和 other无论 *this 的原始值是多少，在自 move 赋值之后最终都是一个零大小的数组。是。这很好。

dumb_array& operator=(dumb_array&& other)
{
    if (this != &other)
    {
        delete [] mArray;
        mSize = other.mSize;
        mArray = other.mArray;
        other.mSize = 0;
        other.mArray = nullptr;
    }
    return *this;
}

上述实现通过使其成为无操作来容忍自赋值，就像复制赋值运算符所做的那样。这也很好。

dumb_array& operator=(dumb_array&& other)
{
    swap(other);
    return *this;
}

以上仅当 dumb_array 时才可以不持有应该“立即”销毁的资源。例如，如果唯一的资源是内存，上面的就可以了。如 dumb_array可能持有互斥锁或文件的打开状态，客户端可以合理地期望 move 分配的 lhs 上的那些资源立即释放，因此这种实现可能有问题。

第一个的成本是两个额外的商店。第二个的成本是测试和分支。两者都有效。两者都满足 C++11 标准中表 22 MoveAssignable 要求的所有要求。第三个也以非内存资源关注为模。

根据硬件的不同，所有三种实现都有不同的成本:分支有多贵？寄存器是多还是少？

结论是，自 move 赋值与自复制赋值不同，不必保留当前值。

</更新 >

受 Luc Danton 评论启发的最后一次(希望如此)编辑:

如果你正在编写一个不直接管理内存的高级类(但可能有基础或成员)，那么 move 分配的最佳实现通常是:

Class& operator=(Class&&) = default;

这将依次分配每个基数和每个成员，并且不包括 this != &other检查。这将为您提供最高的性能和基本的异常安全，假设您的基础和成员之间不需要保持不变。对于需要强大异常安全性的客户，请指向 strong_assign .