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

标签 c++ c++11 move-semantics move-assignment-operator

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

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

    return *this;
}

move 赋值运算符是否需要相同的东西?有没有出现过this == &rhs会是真的吗?
? Class::operator=(Class&& rhs) {
    ?
}

最佳答案

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

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

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

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

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

让我们具体一点:这是 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)到一个右值引用时,它是两件事之一:
  • 一个临时的。
  • 调用者希望您相信的对象是临时对象。

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

    现在,如果您的客户对您撒谎并 promise 您会得到一个临时的,而您却没有,那么客户有责任确保您不必关心。如果您想非常小心,我相信这将是一个更好的实现:
    Class&
    Class::operator=(Class&& other)
    {
        assert(this != &other);
        // ...
        return *this;
    }
    

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

    为了完整起见,这里是 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具有有效但未指定的状态。 IE。自我 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;
    }
    

    上面的实现允许自赋值,但是 *thisother无论 *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 .

    关于c++ - move 赋值运算符和 `if (this != &rhs)`,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55753769/

    相关文章:

    C++ 公共(public)变量作用域混淆

    c++ - 最后一个窗口关闭时的处理提示

    c++ - typeid 的可读形式?

    c++ - char指针的模板特化?

    c++ - 在基于范围的 for 循环中使用转发引用有什么好处?

    c++ - 可变数量的参数,没有宏或初始化列表的相同特定类型

    c++ - 如何让柯南生成 FindXXX.cmake?

    c++ - std::string 引用、std::regex 和 boost::filesystem 的基本概念

    c++ - 将左值绑定(bind)到右值引用 move 构造函数和函数返回

    c++ - 从 boost multi_index 数组中 move 元素