在类的赋值运算符中,你通常需要检查被赋值的对象是否是调用对象,这样你就不会搞砸了:
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;
}
上面的实现允许自赋值,但是
*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
.
关于c++ - move 赋值运算符和 `if (this != &rhs)`,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55753769/