在赋值运算符中移动语义 - 副作用，破坏

Question

Forcing Move Semantics

所以从某种意义上说，我们已经漂入了冥界 这里的非确定性破坏：一个变量已分配给， 但是该变量以前持有的对象仍然存在 某处。 只要销毁该对象就可以了 没有任何外界可见的副作用。但是 有时析构函数确实有这样的副作用。一个例子是 释放析构函数内的锁。因此，任何部分 应该执行具有副作用的对象破坏 在复制赋值的右值引用重载中显式 运营商：

X& X::operator=(X&& rhs)
{

  // Perform a cleanup that takes care of at least those parts of the
  // destructor that have side effects. Be sure to leave the object
  // in a destructible and assignable state.

  // Move semantics: exchange content between this and rhs

  return *this;
}

我知道左值的原始对象通常在非赋值情况下被破坏 - 最终 - 。

但是，在赋值运算符中，你为什么想要同样的行为？

Answer 1

好吧，你必须做你的家务：你有责任将旧对象修改为（安全的）可破坏状态（如果你很好，甚至可以修改为一般有效的对象状态）。一切都是有代价的（甚至是移动语义）。

例如对于典型的向量实现：

V& V::operator=(V&& old){
    auto trash = this->data;
    this->data = old.data;

    //cleanup
    delete[] trash;
    old.data = nullptr; // expecting delete[] of the destructor of old
}

您支付了三个额外的任务（可以通过一个 swap() 技巧优化掉）并且给自己带来了一些不便。你避免了大约 10000 个任务。值得，不是吗？

此外，如果您在析构函数中使用危险的副作用（您不应该这样做），这将不是您遇到的唯一问题。如果您认为这对您的班级有危险，您也可以禁用您的移动作业。

Answer 2

在更仔细地重新阅读了上面的段落之后，我“看到”了答案：当你在析构函数中有副作用时，你希望能够控制这些副作用何时发生。如果您没有在赋值运算符中显式破坏原始 lhs 对象，那么您无法直接控制何时调用其析构函数；稍后添加一些代码可能会延长该对象的寿命。为什么这有关系？就像链接说的那样，如果您的对象只是像Queue<int> 这样的数据，那么谁在乎它何时被破坏。但是，如果您的对象持有锁或影响其他对象的其他资源，那么您希望所述资源的释放是确定性的。