将赋值运算符实现为 "destroy + construct" 是否合法？

Question

我经常需要为 "raw" 资源句柄实现 C++ 包装器，例如文件句柄、Win32 OS 句柄等。这样做时，我还需要实现移动操作符，因为编译器默认生成的操作符不会清除移动对象，从而产生双删除问题。

在实现移动赋值运算符时，我更喜欢显式调用析构函数并就地重新创建放置新的对象。这样，我就避免了析构函数逻辑的重复。此外，我经常根据复制+移动（相关时）来实现复制赋值。这导致以下代码：

/** Canonical move-assignment operator. 
    Assumes no const or reference members. */
TYPE& operator = (TYPE && other) noexcept {
    if (&other == this)
        return *this; // self-assign

    static_assert(std::is_final<TYPE>::value, "class must be final");
    static_assert(noexcept(this->~TYPE()), "dtor must be noexcept");
    this->~TYPE();

    static_assert(noexcept(TYPE(std::move(other))), "move-ctor must be noexcept");
    new(this) TYPE(std::move(other));
    return *this;
}

/** Canonical copy-assignment operator. */
TYPE& operator = (const TYPE& other) {
    if (&other == this)
        return *this; // self-assign

    TYPE copy(other); // may throw

    static_assert(noexcept(operator = (std::move(copy))), "move-assignment must be noexcept");
    operator = (std::move(copy));
    return *this;
}

我觉得很奇怪，但我没有在网上看到任何关于以这种 "canonical" 方式实现移动+复制赋值运算符的建议。相反，大多数网站倾向于以特定于类型的方式实现赋值运算符，在维护 class.

时必须手动与构造函数和析构函数保持同步

是否有任何论据（除了性能之外）反对以这种与类型无关的"canonical"方式实现移动和复制赋值运算符？

根据 UB 评论更新 2019-10-08：

我通读了 http://eel.is/c++draft/basic.life#8 似乎涵盖了相关案例。摘录：

If, after the lifetime of an object has ended ..., a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, ... will automatically refer to the new object and, ..., can be used to manipulate the new object, if ...

此后有一些与相同类型和 const/reference 成员相关的明显条件，但它们似乎是 any 赋值运算符实现所必需的。如果我错了，请纠正我，但在我看来，我的 "canonical" 样本表现良好并且 not UB(?)

根据复制和交换评论更新 2019-10-10：

赋值实现可以合并到一个方法中，该方法采用值参数而不是引用。这似乎也消除了 static_assert 和自我分配检查的需要。我新提出的实施方案变为：

/** Canonical copy/move-assignment operator.
    Assumes no const or reference members. */
TYPE& operator = (TYPE other) noexcept {
    static_assert(!std::has_virtual_destructor<TYPE>::value, "dtor cannot be virtual");
    this->~TYPE();
    new(this) TYPE(std::move(other));
    return *this;
}

Answer 1

对您的 "canonical" 实施有强烈的反对意见 — 这是错误的。

您结束了原始 object 的生命周期，并在其位置上创建了一个 new object。 ~~但是，指向原始 object 的指针、引用等不会自动更新为指向新的 object — 您必须使用 std::launder.~~ （这句话对于大多数 classes 是错误的；参见 Davis Herring 的评论。）然后，析构函数在 original object 上自动调用，触发 undefined behavior.

参考：（强调我的）[class.dtor]/16

Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended. [ Example: If the destructor for an automatic object is explicitly invoked, and the block is subsequently left in a manner that would ordinarily invoke implicit destruction of the object, the behavior is undefined. — end example ]

[basic.life]/1

[...] The lifetime of an object o of type T ends when:

if T is a class type with a non-trivial destructor ([class.dtor]), the destructor call starts, or

the storage which the object occupies is released, or is reused by an object that is not nested within o ([intro.object]).

（根据你的 class 的析构函数是否平凡，结束 object 生命周期的代码行是不同的。如果析构函数是 non-trivial，明确调用析构函数结束 object 的生命周期；否则，放置 new 重新使用当前 object 的存储，结束其生命周期。无论哪种情况，object 的生命周期都已结束当赋值运算符 returns.)

时结束

您可能认为这是另一种 "any sane implementation will do the right thing" 未定义行为，但实际上许多编译器优化都涉及缓存值，它们利用了此规范。因此，当代码在不同的优化级别下、由不同的编译器、使用同一编译器的不同版本编译时，或者当编译器刚刚度过糟糕的一天并且心情不好时，您的代码随时可能中断。

实际的 "canonical" 方法是使用 copy-and-swap idiom:

// copy constructor is implemented normally
C::C(const C& other)
    : // ...
{
    // ...
}

// move constructor = default construct + swap
C::C(C&& other) noexcept
    : C{}
{
    swap(*this, other);
}

// assignment operator = (copy +) swap
C& C::operator=(C other) noexcept // C is taken by value to handle both copy and move
{
    swap(*this, other);
    return *this;
}

请注意，在这里，您需要提供自定义 swap 函数而不是使用 std::swap，正如 Howard Hinnant 所提到的：

friend void swap(C& lhs, C& rhs) noexcept
{
    // swap the members
}

如果使用得当，copy-and-swap 如果相关函数被正确内联（这应该是非常微不足道的），则不会产生开销。这个习惯用语很常用，普通的 C++ 程序员理解它应该没有什么困难。与其怕它会造成混淆，不如花2分钟学会它，然后使用它。

这一次，我们交换 object 的值，object 的生命周期不受影响。 object还是原来的object，只是数值不同而已，不是全新的object。这样想：你想阻止孩子欺负别人。交换价值观就像对他们进行文明教育，而"destroying + constructing"就像~~杀死他们~~让他们暂时死亡 并给他们一个全新的大脑（可能借助魔法）。至少可以说，后一种方法可能会产生一些不良副作用。

像任何其他成语一样，在适当的时候使用它——不要只是为了使用它而使用它。

Answer 2

我相信 http://eel.is/c++draft/basic.life#8 中的示例清楚地证明赋值运算符可以通过就地“销毁 + 构造”实现，假设某些与非常量、非- 重叠对象等等。

将赋值运算符实现为 "destroy + construct" 是否合法？

Is it legal to implement assignment operators as "destroy + construct"?

c++

assignment-operator

move-semantics

move-assignment-operator

根据 UB 评论更新 2019-10-08：

根据复制和交换评论更新 2019-10-10：