C ++ std :: move在这里不好？

Question

假设我具有带有move constructor和operator=(Foo&&) struct Foo ，并将其用作数据成员：

Foo f()
{
  Foo foo;
  //code
  return foo; 
}
struct Boo {
Foo foo;
Boo() {
  foo = f();//1
  foo = std::move(f());//2
}
};

在情况（2）中，我实际上不需要std::move ，但是如果我在这里使用它，会带来不好的事情，例如阻止优化吗？

我读到这： 为什么std :: move可以防止RVO？

并找出变化的return foo; return std::move(foo); 导致禁用RVO ，但是（2）会导致类似情况吗？ 如果是这样，为什么？

Answer 1

这是多余的和令人困惑的。 仅仅因为我可以写std::add_pointer_t<void>代替void* ，或std::add_lvalue_reference_t<Foo> （或Foo bitand ）代替Foo& ， Foo bitand并不意味着我应该这样做。

在其他情况下也很重要：

auto&& a = f(); // OK, reference binding to a temporary extends its lifetime
auto&& b = std::move(f()); // dangling

因此，如果Foo是可以迭代的东西，

for(const auto& p : f()) {} // OK
for(const auto& p : std::move(f())) {} // UB

在您的示例中，如果将赋值运算符实现为复制和交换（ operator=(Foo) ），则foo = std::move(f())强制执行不可删除的移动，而foo = f()可以忽略从f()的返回值到operator=参数的移动。