一段小代码秒懂C++右值引用和RVO(返回值优化)的误区

关于C++右值引用的参考文档里面有明确提到,右值引用可以延长临时变量的周期。如:

std::string&& r3 = s1 + s1; // okay: rvalue reference extends lifetime

看到这里的时候,Binfun有点崩溃,就这就能延长生命周期?这个和以下的这样的命令有啥本质的区别吗?

std::string r3 = s1 + s1

所以Binfun写了一段小代码来测试一下右值引用的延长生命周期的特性,如:

#include <stdio.h>
#include <utility>//std::move

class result {
public:
  int val;
  result() { printf("constructor() [%p]\n", this); }
  result(result& r): val(r.val) { printf("copying from [%p] to [%p]\n", &r, this); }
  result(result&& r): val(r.val) { printf("moving from [%p] to [%p]\n", &r, this); }
  result(int i): val(i) { printf("constructor(%d) [%p]\n", val, this); }
  ~result() { printf("destructor() [%p]\n", this); }
};

result process(int i)
{
  printf("In process function\n");
  return result(i);
}

int main()
{
  printf("---step1---\n");
  result s1 = process(1);
  printf("---step2---\n");
  result &&s2 = process(2);

  printf("---vals:---\n");
  printf("s1 addr:[%p], val:[%d]\n", &s1, s1.val);
  printf("s2 addr:[%p], val:[%d]\n", &s2, s2.val);
}

然后Binfun自信满满地敲了编译并执行命令:

g++ new_move.cpp -std=c++11 -O2 && ./a.out

看到打印的时候Binfun再一次崩溃了:

---step1---
In process function
constructor(1) [0x7ffd94c8aca0]
---step2---
In process function
constructor(2) [0x7ffd94c8acb0]
---vals:---
s1 addr:[0x7ffd94c8aca0], val:[1]
s2 addr:[0x7ffd94c8acb0], val:[2]
destructor() [0x7ffd94c8acb0]
destructor() [0x7ffd94c8aca0]

这……没有任何区别啊,C++国际标准委员会逗我玩呢?

RVO和右值引用

其实是有区别的,先听我解释一下RVO这个概念:返回值优化

返回值优化(Return value optimization,缩写为RVO)是C++的一项编译优化技术。即删除保持函数返回值的临时对象。这可能会省略多次复制构造函数

在调用process函数的时候竟然没有临时变量产生(可以看到构造函数只运行了一次),那应该是被RVO了。既然是编译优化技术,那么应该有编译选项关闭,RVO优化在C++里面也叫copy_elision(复制消除)优化。使用以下命令即可取消RVO:

g++ new_move.cpp -std=c++11 -fno-elide-constructors -O2 && ./a.out

编译后打印如下:

---step1---
In process function
constructor(1) [0x7ffe849b8a70]
moving from [0x7ffe849b8a70] to [0x7ffe849b8ab0]
destructor() [0x7ffe849b8a70]
moving from [0x7ffe849b8ab0] to [0x7ffe849b8aa0]
destructor() [0x7ffe849b8ab0]
---step2---
In process function
constructor(2) [0x7ffe849b8a70]
moving from [0x7ffe849b8a70] to [0x7ffe849b8ab0]
destructor() [0x7ffe849b8a70]
---vals:---
s1 addr:[0x7ffe849b8aa0], val:[1]
s2 addr:[0x7ffe849b8ab0], val:[2]
destructor() [0x7ffe849b8ab0]
destructor() [0x7ffe849b8aa0]

可以看到在step1中调用process函数的时候,构造产生了一个变量(地址为0x7ffe849b8a70),然后函数返回时将这个变量移动构造到了另一个临时变量(地址为0x7ffe849b8ab0),接着赋值给s2(地址为0x7ffe849b8aa0)时再一次调用了移动构造函数。

之所以以上调用的都是移动构造,这是因为编译器识别出这些变量都是“将亡值”,也就是说编译器知道这个变量接下来都会离开它的作用域,即将会被析构掉,此时认定它是一个右值&&,所以也就调用的是移动构造函数。打印中也体现了这一点,0x7ffe849b8a70和0x7ffe849b8ab0被move constructor之后立马就被析构掉了。

而step2就不一样了,我们看到了移动构造函数只被调用了一次。而这一次0x7ffe849b8ab0并没有被析构掉,这一次它被保留了下来,它的生命周期被延长了,直到main函数结束时它才会析构掉。

以上可以看到右值引用的确可以延长右值变量的生命周期。当然尽管在RVO的光环下,只需要构造一次就已经到位了,就没必要去延长生命周期了-。-|||

std::move和右值引用的坑

另外Binfun进一步理解移动语义的时候,发现了一个坑,希望大家关注一下。这个坑会导致奇怪的问题发生……也会导致很隐蔽的bug……

在说这个例子的时候,我们先介绍一下std::move(懂的可以略过-。-)

文章最下面的参考链接里面的文章有一段写得特别棒,如下:

关于move函数内部到底是怎么实现的,其实std::move函数并不“移动”,它仅仅进行了类型转换。下面给出一个简化版本的std::move:

template <typename T>
typename remove_reference<T>::type&& move(T&& param)
{
    using ReturnType = typename remove_reference<T>::type&&;
    return static_cast<ReturnType>(param);
}

代码很短,但是估计很难懂。首先看一下函数的返回类型,remove_reference在头文件中,remove_reference 有一个成员type,是T去除引用后的类型,所以remove_reference ::type&&一定是右值引用,对于返回类型为右值的函数其返回值是一个右值(准确地说是xvalue)。所以,知道了std::move函数的返回值是一个右值。然后,我们看一下函数的参数,使用的是通用引用类型(&&),意味者其可以接收左值,也可以接收右值。但是不管怎么推导,ReturnType的类型一定是右值引用,最后std::move函数只是简单地调用static_cast将参数转化为右值引用。

还是同样的result类和同样的process函数,我们修改一下main函数为:

int main()
{
  printf("---step1---\n");
  result &&s1 = std::move(process(1));
  printf("---step2---\n");
  process(2);

  printf("---vals:---\n");
  printf("s1 addr:[%p], val:[%d]\n", &s1, s1.val);
}

猜猜最后打印中s1.val的值是1还是2?

g++ new_move.cpp -std=c++11 -O2 && ./a.out

以上的编译选项的打印如下:

---step1---
In process function
constructor(1) [0x7ffdf1352db0]
destructor() [0x7ffdf1352db0]
---step2---
In process function
constructor(2) [0x7ffdf1352db0]
destructor() [0x7ffdf1352db0]
---vals:---
s1 addr:[0x7ffdf1352db0], val:[2]

g++ new_move.cpp -std=c++11 -fno-elide-constructors -O2 && ./a.out

以上的编译选项,打印结果如下:

---step1---
In process function
constructor(1) [0x7ffe7d59f350]
moving from [0x7ffe7d59f350] to [0x7ffe7d59f380]
destructor() [0x7ffe7d59f350]
destructor() [0x7ffe7d59f380]
---step2---
In process function
constructor(2) [0x7ffe7d59f350]
moving from [0x7ffe7d59f350] to [0x7ffe7d59f380]
destructor() [0x7ffe7d59f350]
destructor() [0x7ffe7d59f380]
---vals:---
s1 addr:[0x7ffe7d59f380], val:[2]

很可惜都是2,不管有没有RVO优化都是2。

Binfun的理解是,因为std::move的显式声明的关系,result &&s1 = 这种让右值生命值延长的方法失效了,最终s1指向的是已经被析构掉的右值地址(如上的0x7ffe7d59f380),而因为编译器优化等级的关系,编译器会重新回收并利用这个地址。所以在调用process(2)的时候会重新使用0x7ffe7d59f380这个地址。

如果编译选项的优化等级没那么高的话(以下把优化等级降为O1),会暂时避免这个问题:

g++ new_move.cpp -std=c++11 -O1 -fno-elide-constructors && ./a.out

打印如下:

---step1---
In process function
constructor(1) [0x7ffca4276e50]
moving from [0x7ffca4276e50] to [0x7ffca4276e80]
destructor() [0x7ffca4276e50]
destructor() [0x7ffca4276e80]
---step2---
In process function
constructor(2) [0x7ffca4276e50]
moving from [0x7ffca4276e50] to [0x7ffca4276e90]
destructor() [0x7ffca4276e50]
destructor() [0x7ffca4276e90]
---vals:---
s1 addr:[0x7ffca4276e80], val:[1]

可以看到以上0x7ffca4276e80虽然被析构了,但是没有那么快被重新利用起来,第二次使用的是0x7ffca4276e90,所以结果是正确的1。但是result &&s1 = std::move(process(1))这样的使用方式应该坚决不要用!

所以记住啊,这样可以:

result s1 = std::move(process(1)); //OK

这样也可以:

result &&s1 = process(1); //OK

这样不可以哦!:

result &&s1 = std::move(process(1)); //Error sometimes

参考链接

  1. https://www.cnblogs.com/tianfang/archive/2013/01/26/2878356.html
  2. https://zhuanlan.zhihu.com/p/107445960
  3. https://www.yhspy.com/2019/09/01/C-编译器优化之-RVO-与-NRVO/
  4. https://zhuanlan.zhihu.com/p/54050093
  5. http://stupefydeveloper.blogspot.com/2008/10/c-rvo-and-nrvo.html
  6. https://en.cppreference.com/w/cpp/language/reference
  7. https://zh.wikipedia.org/wiki/返回值优化
  8. https://en.wikipedia.org/wiki/Copy_elision
  9. https://zh.wikipedia.org/wiki/值_(電腦科學)
  10. 极客时间专栏《现代C++实战30讲》 03 | 右值和移动究竟解决了什么问题?
发表评论

相关文章