6

使用 std::string 的移动赋值运算符（在 VC11 中）需要什么？

我希望它会自动使用，因为分配后不再需要 v 。在这种情况下需要 std::move 吗？如果是这样，我不妨使用非 C++11 交换。

#include <string>

struct user_t
{
    void set_name(std::string v)
    {
        name_ = v;
        // swap(name_, v);
        // name_ = std::move(v);
    }

    std::string name_;
};

int main()
{
    user_t u;
    u.set_name("Olaf");
    return 0;
}
4

3 回答 3

11

我希望它会自动使用，因为分配后不再需要 v 。在这种情况下需要 std::move 吗？

必须为左值明确说明运动，除非它们是从函数（按值）返回的。

这可以防止意外移动某些东西。记住：运动是一种破坏性的行为；你不希望它发生。

name_ = v;此外，如果根据这是否是函数中的最后一行来改变语义，那会很奇怪。毕竟，这是完全合法的代码：

name_ = v;
v[0] = 5; //Assuming v has at least one character.

为什么第一行有时会执行一个副本，而有时会执行一次移动？

如果是这样，我不妨使用非 C++11 交换。

你可以随心所欲，但std::move意图更明显。我们知道它的含义以及您正在用它做什么。

于 2012-05-07T21:43:37.657 回答
7

接受的答案是一个很好的答案（我已经赞成）。但我想更详细地解决这个问题：

我的问题的核心是：为什么它不自动选择移动赋值运算符？编译器知道 v 在赋值后没有使用，不是吗？还是 C++11 不需要编译器那么聪明？

在设计移动语义时考虑了这种可能性。在极端情况下，您可能希望编译器进行一些静态分析并尽可能从对象中移动：

void set_name(std::string v)
{
    name_ = v;  // move from v if it can be proven that some_event is false?
    if (some_event)
       f(v);
}

最终要求编译器进行这种分析是非常棘手的。一些编译器可能能够证明，而其他编译器可能不能。从而导致代码不是真正可移植的。

好的，那么一些没有 if 语句的更简单的情况呢？

void foo()
{
    X x;
    Y y(x);
    X x2 = x;  // last use?  move?
}

好吧，很难知道是否y.~Y()会通知x已被移出。一般来说：

void foo()
{
    X x;
    // ...
    // lots of code here
    // ...
    X x2 = x;  // last use?  move?
}

编译器很难对此进行分析以知道x在复制构造后是否真的不再使用 to x2。

所以最初的“移动”提议给出了一个非常简单且非常保守的隐式移动规则：

只有在已经允许复制省略的情况下，左值才能被隐式移动。

例如：

#include <cassert>

struct X
{
    int i_;
    X() : i_(1) {}
    ~X() {i_ = 0;}
};

struct Y
{
    X* x_;
    Y() : x_(0) {}
    ~Y() {assert(x_ != 0); assert(x_->i_ != 0);}
};

X foo(bool some_test)
{
    Y y;
    X x;
    if (some_test)
    {
        X x2;
        return x2;
    }
    y.x_ = &x;
    return x;
}

int main()
{
    X x = foo(false);
}

在这里，根据 C++98/03 规则，这个程序可能会或可能不会断言，这取决于是否return x发生复制省略。如果确实发生了，程序运行良好。如果没有发生，则程序断言。

因此有理由认为：当允许 RVO 时，我们已经处于无法保证x. 所以我们应该能够利用这个余地并从x. 风险看起来很小，收益看起来很大。这不仅意味着通过简单的重新编译，许多现有程序会变得更快，而且还意味着我们现在可以从工厂函数返回“仅移动”类型。这是一个非常大的收益风险比。

在标准化过程的后期，我们有点贪心，还说在返回按值参数时会发生隐式移动（并且类型与返回类型匹配）。这里的好处似乎也相对较大，尽管代码破坏的机会稍大一些，因为这不是 RVO 合法（或现在）合法的情况。但是我没有演示这种情况下的破解代码。

所以最终，你的核心问题的答案是移动语义的原始设计在破坏现有代码方面采取了非常保守的路线。如果不是这样，它肯定会在委员会中被击落。在这个过程的后期，有一些变化使设计更具侵略性。但到了这个时候，核心提案已经在标准中根深蒂固，得到了多数（但不是一致）的支持。

于 2012-05-08T00:46:52.273 回答
5

在您的示例中，set_name按值获取字符串。set_name然而，里面v 是一个左值。让我们分别处理这些情况：

user_t u;
std::string str("Olaf");    // Creates string by copying a char const*.
u.set_name(std::move(str)); // Moves string.

在内部set_name调用 的赋值运算符std::string，这会产生不必要的副本。但是还有一个rvalue 重载，operator=这在您的情况下更有意义：

void set_name(std::string v)
{
    name_ = std::move(v);
}

这样，唯一发生的复制是字符串构造 ( std::string("Olaf"))。

于 2012-05-07T21:39:07.080 回答