【问题标题】:Can I typically/always use std::forward instead of std::move?我可以通常/总是使用 std::forward 而不是 std::move 吗?
【发布时间】:2012-10-24 13:02:56
【问题描述】:

我一直在观看 Scott Meyers 在 C++ 和 Beyond 2012 会议上的talk on Universal References,到目前为止一切都很有意义。然而,一位观众在大约 50 分钟时提出了一个我也想知道的问题。 Meyers 说他不关心答案,因为它不习惯用语并且会让他觉得很傻,但我仍然感兴趣。

呈现的代码如下:

// Typical function bodies with overloading:
void doWork(const Widget& param)   // copy
{
  // ops and exprs using param
}
void doWork(Widget&& param)        // move
{
  // ops and exprs using std::move(param)
}

// Typical function implementations with universal reference:
template <typename T>
void doWork(T&& param)             // forward => copy and move
{
  // ops and exprs using std::forward<T>(param)
}

关键是当我们获取一个右值引用时,我们知道我们有一个右值,所以我们应该std::move 它来保留它是一个右值的事实。当我们采用通用引用(T&amp;&amp;,其中T 是推导类型)时,我们希望std::forward 保留它可能是左值或右值的事实。

所以问题是:既然std::forward 保留了传递给函数的值是左值还是右值,而std::move 只是将其参数转换为右值,我们可以在任何地方都使用std::forward 吗?在我们使用 std::move 的所有情况下,std::forward 的行为会像 std::move 一样吗,还是 Meyers 的概括遗漏了一些重要的行为差异?

我并不是建议任何人都应该这样做,因为正如 Meyers 正确所说,它完全不习惯,但以下也是 std::move 的有效用法:

void doWork(Widget&& param)         // move
{
  // ops and exprs using std::forward<Widget>(param)
}

【问题讨论】:

  • move(lvalue) 将参数转换为右值。 forward(lvalue) 将其保留为左值。
  • @AndrewTomazos-Fathomling std::forward(lvalue_expression) 如果lvalue_expression 的类型是左值,它将给出一个左值,如果lvalue_expression 的类型是右值,它将给出一个右值(在例如,命名的右值)。在这里,我在我知道具有右值类型的表达式上使用 std::forward
  • @Andrew Tomazos - Fathomling - 这是错误的,std::forward 的全部意义在于它有时可以将左值更改为右值。
  • 这个术语有点含糊。当我说 forward(lvalue) 时,我的意思是一个通过引用折叠推导出类型 T& 的参数。

标签: c++ c++11 move-semantics rvalue-reference perfect-forwarding


【解决方案1】:

两者是非常不同且互补的工具。

  • std::move推导出参数并无条件地创建一个右值表达式。这适用于实际的对象或变量是有意义的。

  • std::forward 接受一个强制模板参数(你必须指定这个!)并根据类型神奇地创建一个左值或右值表达式(通过添加&amp;&amp; 和折叠规则)。这仅适用于推导的模板化函数参数。

也许下面的例子能更好地说明这一点:

#include <utility>
#include <memory>
#include <vector>
#include "foo.hpp"

std::vector<std::unique_ptr<Foo>> v;

template <typename T, typename ...Args>
std::unique_ptr<T> make_unique(Args &&... args)
{
    return std::unique_ptr<T>(new T(std::forward<Args>(args)...));  // #1
}

int main()
{
    {
        std::unique_ptr<Foo> p(new Foo('a', true, Bar(1,2,3)));
        v.push_back(std::move(p));                                  // #2
    }

    {
        v.push_back(make_unique<Foo>('b', false, Bar(5,6,7)));      // #3
    }

    {
        Bar b(4,5,6);
        char c = 'x';
        v.push_back(make_unique<Foo>(c, b.ready(), b));             // #4
    }
}

在情况 #2 中,我们有一个现有的具体对象p,我们想无条件地离开它。只有std::move 有意义。这里没有什么可以“转发”的。我们有一个命名变量,我们想从它移开。

另一方面,情况 #1 接受任何类型的参数列表,并且每个参数都需要作为与原始调用中相同的值类别进行转发。例如,在#3 中,参数是临时表达式,因此它们将作为右值转发。但我们也可以在构造函数调用中混合命名对象,如情况 #4,然后我们需要作为左值转发。

【讨论】:

  • 尽管我不想这样做,但我必须为此给出 +1,因为我的回答基本上是一样的。该死的,如果这样下去,你真的会得到第四个 C++11 金牌。 :P
  • 嘿,你还没有。 :) 您需要在标签中获得更多支持,我仍然希望在您获得这些选票之前获得我的“更多答案”。 :P
  • 为什么有人会移动 unique_ptr ?我错过了什么吗?上面的例子不是试图移动一个unique_ptr的存储吗?为什么这有意义?
  • @Gabriel:没有这个动作,它就行不通。 std::unique_ptr 无法复制。
  • @Gabriel:你误会了:你总是移动资源handle,而不是资源本身。根据定义,资源是不可移动的实体;可移动的是资源所有权
【解决方案2】:

是的,如果paramWidget&amp;&amp;,那么下面三个表达式是等价的(假设Widget不是引用类型):

std::move(param)
std::forward<Widget>(param)
static_cast<Widget&&>(param)

一般情况下(当Widget 可能是引用时),std::move(param) 等价于以下两个表达式:

std::forward<std::remove_reference<Widget>::type>(param)
static_cast<std::remove_reference<Widget>::type&&>(param)

请注意std::move 用于移动物品要好得多。 std::forward的重点在于它与模板类型推演规则很好的融合:

template<typename T>
void foo(T&& t) {
    std::forward<T>(t);
    std::move(t);
}

int main() {
    int a{};
    int const b{};
               //Deduced T   Signature    Result of `forward<T>` Result of `move`
    foo(a);    //int&        foo(int&)       lvalue int          xvalue int
    foo(b);    //int const&  foo(int const&) lvalue int const    xvalue int const
    foo(int{});//int         foo(int&&)      xvalue int          xvalue int
}

【讨论】:

  • 除非Widget&amp;&amp; 是推导类型,例如template&lt;class Widget&gt; f(Widget&amp;&amp; x)
  • @Andrew Tomazos - Fathomling - 当然。我假设 Widget 是非引用类型(如问题中的示例所示)。
猜你喜欢
  • 2013-06-25
  • 1970-01-01
  • 2016-07-08
  • 2015-05-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-03-21
  • 1970-01-01
相关资源
最近更新 更多