8

我经常需要为“原始”资源句柄（如文件句柄、Win32 OS 句柄等）实现 C++ 包装器。这样做时，我还需要实现移动运算符，因为默认的编译器生成的不会清除移动的对象，从而产生双重删除问题。

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

/** 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;
}

这让我觉得很奇怪，但我没有在网上看到任何关于以这种“规范”方式实现移动+复制分配运算符的建议。相反，大多数网站倾向于以特定类型的方式实现赋值运算符，在维护类时必须手动与构造函数和析构函数保持同步。

是否有反对以这种与类型无关的“规范”方式实现移动和复制赋值运算符的论点（除了性能）？

更新 2019-10-08 基于 UB 评论：

我已经阅读了http://eel.is/c++draft/basic.life#8似乎涵盖了相关案例。提炼：

如果，在对象的生命周期结束后......，在原始对象占用的存储位置创建一个新对象，一个指向原始对象的指针，一个指向原始对象的引用，......将自动引用新对象，并且，...，可用于操作新对象，如果...

此后有一些明显的条件与相同的类型和 const/reference 成员相关，但它们似乎是任何赋值运算符实现所必需的。如果我错了，请纠正我，但这在我看来就像我的“规范”样本表现良好而不是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;
}
4

2 回答 2

3

有一个强烈的论据反对你的“规范”实现——这是错误的。

您结束原始对象的生命周期并在其位置创建一个新对象。 但是，指向原始对象的指针、引用等不会自动更新为指向新对象——您必须使用std::launder. （这句话对于大多数类来说都是错误的；请参阅 Davis Herring 的评论。）然后，在原始对象上自动调用析构函数，触发未定义的行为。

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

一旦为对象调用析构函数，该对象就不再存在；如果为生命周期已结束的对象调用析构函数，则行为未定义。[ 示例：如果自动对象的析构函数被显式调用，并且块随后以通常会调用对象的隐式销毁的方式离开，则行为未定义。— 结束示例 ]

[基本生活]/1

[...]类型的对象oT的生命周期在以下情况下结束：

  • 如果T是具有非平凡析构函数 ([class.dtor]) 的类类型，则析构函数调用开始，或者

  • 对象占用的存储空间被释放，或者被未嵌套在o ([intro.object]) 中的对象重用。

（取决于你的类的析构函数是否平凡，结束对象生命周期的代码行不同。如果析构函数不平凡，显式调用析构函数结束对象的生命周期；否则，放置new重用当前对象的存储，结束它的生命周期。在任何一种情况下，当赋值运算符返回时，对象的生命周期已经结束。）

您可能认为这是另一种“任何理智的实现都会做正确的事情”的未定义行为，但实际上许多编译器优化都涉及缓存值，这利用了这个规范。因此，当代码在不同的优化级别下、由不同的编译器、使用同一编译器的不同版本或编译器刚刚度过糟糕的一天并且心情不好时，您的代码可能随时中断。

实际的“规范”方式是使用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函数而不是 using std::swap，如 Howard Hinnant 所述：

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

如果使用得当，如果相关函数被正确内联（这应该是微不足道的），则复制和交换不会产生任何开销。这个成语非常常用，一般的 C++ 程序员应该不难理解它。与其害怕它会引起混乱，不如花2分钟学习它，然后使用它。

这一次，我们交换对象的值，对象的生命周期不受影响。该对象仍然是原始对象，只是具有不同的值，而不是全新的对象。这样想：你想阻止一个孩子欺负别人。交换价值观就像文明教育他们，而“破坏+建设”就像杀死他们 让他们 暂时死亡并给他们一个全新的大脑（可能在魔法的帮助下）。至少可以说，后一种方法可能会产生一些不良副作用。

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

于 2019-10-08T10:35:37.790 回答
0

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

于 2021-09-02T21:41:02.237 回答