25

通过使用Copy & Swap习惯用法,我们可以轻松实现具有强大异常安全性的复制分配:

T& operator = (T other){
    using std::swap;
    swap(*this, other);
    return *this;
}

但是,这T需要Swappable。如果std::is_move_constructible_v<T> && std::is_move_assignable_v<T> == true感谢std::swap.

我的问题是,使用“复制和移动”习语有什么缺点吗?像这样:

T& operator = (T other){
    *this = std::move(other);
    return *this;
}

前提是你实现了移动赋值,T因为显然你最终会得到无限递归。

这个问题与 Copy-and-Swap 成语是否应该成为 C++11 中的 Copy-and-Move 成语不同?因为这个问题更笼统,并且使用移动赋值运算符而不是实际手动移动成员。这避免了在链接线程中预测答案的清理问题。

4

2 回答 2

11

更正问题

实现复制和移动的方式必须像@Raxvan 指出的那样:

T& operator=(const T& other){
    *this = T(other);
    return *this;
}

但是如果没有std::moveasT(other)已经是一个右值,并且在此处使用时,clang 会发出关于悲观化的警告std::move

概括

当存在移动赋值运算符时,Copy & Swap 和 Copy & Move 之间的区别取决于用户是否使用了swap比移动赋值具有更好异常安全性的方法。对于标准std::swap,复制和交换与复制和移动之间的异常安全性是相同的。我相信在大多数情况下,swap移动分配将具有相同的异常安全性(但并非总是如此)。

实施复制和移动存在风险,如果移动赋值运算符不存在或签名错误,则复制赋值运算符将减少为无限递归。但是,至少 clang 对此发出警告,并且通过将这种恐惧传递-Werror=infinite-recursion给编译器可以消除这种恐惧,坦率地说,这超出了我为什么默认情况下这不是错误的原因,但我离题了。

动机

我已经做了一些测试和很多挠头,这就是我发现的:

  1. 如果您有一个移动赋值运算符,则由于调用operator=(T)operator=(T&&). 正如@Raxvan 指出的那样,您需要在复制赋值运算符的主体内进行复制构造。这被认为是劣等的,因为它可以防止编译器在使用右值调用运算符时执行复制省略。但是,应用复制省略的情况现在由移动分配处理,因此这一点没有实际意义。

  2. 我们必须比较:

    T& operator=(const T& other){
        using std::swap;
        swap(*this, T(other));
        return *this;
    }
    

    至:

    T& operator=(const T& other){
        *this = T(other);
        return *this;
    }
    

    如果用户不使用自定义swap,则使用模板std::swap(a,b)。这基本上是这样做的:

    template<typename T>
    void swap(T& a, T& b){
        T c(std::move(a));
        a = std::move(b);
        b = std::move(c);
    }
    

    这意味着 Copy & Swap 的异常安全性与 move 构造和 move assignment 中较弱的异常安全性相同。如果用户正在使用自定义交换,那么异常安全当然由交换函数决定。

    在复制和移动中,异常安全完全由移动赋值运算符决定。

    我相信在这里查看性能有点没有意义,因为编译器优化可能在大多数情况下没有区别。但是无论如何我都会评论它,复制和交换执行复制构造,移动构造和两个移动分配,而复制和移动执行复制构造和仅一个移动分配。尽管我有点期待编译器在大多数情况下都能生成相同的机器代码,当然这取决于 T.

附录:我使用的代码

  class T {
  public:
    T() = default;
    T(const std::string& n) : name(n) {}
    T(const T& other) = default;

#if 0
    // Normal Copy & Swap.
    // 
    // Requires this to be Swappable and copy constructible. 
    // 
    // Strong exception safety if `std::is_nothrow_swappable_v<T> == true` or user provided
    // swap has strong exception safety. Note that if `std::is_nothrow_move_assignable` and
    // `std::is_nothrow_move_constructible` are both true, then `std::is_nothrow_swappable`
    // is also true but it does not hold that if either of the above are true that T is not
    // nothrow swappable as the user may have provided a specialized swap.
    //
    // Doesn't work in presence of a move assignment operator as T t1 = std::move(t2) becomes
    // ambiguous.
    T& operator=(T other) {
      using std::swap;
      swap(*this, other);
      return *this;
    }
#endif

#if 0
    // Copy & Swap in presence of copy-assignment.
    //
    // Requries this to be Swappable and copy constructible.
    //
    // Same exception safety as the normal Copy & Swap. 
    // 
    // Usually considered inferor to normal Copy & Swap as the compiler now cannot perform
    // copy elision when called with an rvalue. However in the presence of a move assignment
    // this is moot as any rvalue will bind to the move-assignment instead.
    T& operator=(const T& other) {
      using std::swap;

      swap(*this, T(other));
      return *this;
    }
#endif

#if 1
    // Copy & Move
    //
    // Requires move-assignment to be implemented and this to be copy constructible.
    //
    // Exception safety, same as move assignment operator.
    //
    // If move assignment is not implemented, the assignment to this in the body
    // will bind to this function and an infinite recursion will follow.
    T& operator=(const T& other) {
      // Clang emits the following if a user or default defined move operator is not present.
      // > "warning: all paths through this function will call itself [-Winfinite-recursion]"
      // I recommend  "-Werror=infinite-recursion" or "-Werror" compiler flags to turn this into an
      // error.

      // This assert will not protect against missing move-assignment operator.
      static_assert(std::is_move_assignable<T>::value, "Must be move assignable!");

      // Note that the following will cause clang to emit:
      // warning: moving a temporary object prevents copy elision [-Wpessimizing-move]

      // *this = std::move(T{other});

      // The move doesn't do anything anyway so write it like this;
      *this = T(other);
      return *this;
    }
#endif

#if 1
    T& operator=(T&& other) {
      // This will cause infinite loop if user defined swap is not defined or findable by ADL
      // as the templated std::swap will use move assignment.

      // using std::swap;
      // swap(*this, other);

      name = std::move(other.name);
      return *this;
    }
#endif

  private:
    std::string name;
  };
于 2017-04-12T14:46:10.567 回答
4

我的问题是,使用“复制和移动”习语有什么缺点吗?

是的,如果你不实现移动赋值,你会得到堆栈溢出operator =(T&&)。如果你确实想实现它,你会得到一个编译器错误(这里的例子):

struct test
{
    test() = default;
    test(const test &) = default;

    test & operator = (test t)
    {
        (*this) = std::move(t);
        return (*this);
    }

    test & operator = (test &&)
    {
        return (*this);
    }

};

如果你这样做test a,b; a = b;了,你会得到错误:

error: ambiguous overload for 'operator=' (operand types are 'test' and 'std::remove_reference<test&>::type {aka test}')

解决此问题的一种方法是使用复制构造函数:

test & operator = (const test& t)
{
    *this = std::move(test(t));
    return *this;
}

这将起作用,但是如果您不实现移动分配,您可能不会收到错误(取决于编译器设置)。考虑到人为错误,这种情况可能会发生,并且您最终会在运行时发生堆栈溢出,这很糟糕。

于 2017-04-12T12:15:06.487 回答