当 RVO 可以应用时，为什么要按shared_ptr而不是按值返回?

Why return by shared_ptr instead of by value when RVO could apply?

本文关键字：ptr 返回 shared 应用 为什么 RVO      更新时间：2023-10-16

我最近开始通读"C++并发操作"，我对完全独立于并发 API 的C++功能了解了多少感到惊讶。但是，有一个我无法弄清楚的例子：当 RVO 可以应用时，书中的几个示例并发数据结构按shared_ptr而不是按值返回。(不过，我绝对是一个C++新手，所以也许真正的问题是我对RVO的理解。

这本书对它的线程安全队列是这样说的："从内部std::queue<>中复制std::shared_ptr<>不会引发异常，所以wait_and_pop()又是安全的"。这本书似乎暗示，如果只有在队列被修改后才将弹出的值返回给调用方，那么拥有数据值的内部队列而不是内部shared_ptrs队列可能会导致问题。如果复制数据以返回到调用方的过程引发异常，则刚刚弹出的数据将丢失，但堆栈仍会被修改。

让我粘贴教科书中的直接引用，以防我误解他们在说什么：

"对于那些不知道这个问题的人，请考虑stack<vector<int>>。现在，向量是一个动态大小的容器，因此当您复制向量时，库必须从堆中分配更多内存才能复制内容。如果系统负载过重，或者存在严重的资源限制，则此内存分配可能会失败，因此 vector 的复制构造函数可能会引发std::bad_alloc异常。如果向量包含大量元素，则尤其可能发生这种情况。如果pop()函数定义为返回弹出的值，并将其从堆栈中删除，则存在潜在问题：只有在修改堆栈后，才会将弹出的值返回给调用方，但复制数据以返回到调用方的过程可能会引发异常。如果发生这种情况，刚刚弹出的数据将丢失;它已从堆栈中删除，但复制不成功！std：：stack 接口的设计者很有帮助地将操作一分为二：获取顶部元素 (top()(，然后将其从堆栈中删除 (pop()(，这样如果你不能安全地复制数据，它就会留在堆栈上。如果问题是堆内存不足，也许应用程序可以释放一些内存并重试。

有问题的pop()函数采取的步骤是：

  1. 获取最上面的值并将其存储为局部变量

  2. 从堆栈中弹出值

  3. 返回值

我的问题是：返回值优化如何出现这种异常情况？如果满足复制 elision 的条件，但编译器选择不执行副本 elision，则必须将返回的对象视为右值。实际上，该标准要求在允许 RVO 时，要么进行复制省略，要么将std::move()隐式应用于要返回的本地对象。上述情况绝对符合RVO的条件。因此，移动对象的成本要么是单次移动(无 RVO，对象被视为右值(，要么什么都不移动 (RVO(。那么，将值移出shared_ptr真的有必要吗？

简短的回答是因为您的情况不RVO。
在 return 语句中创建对象时，会发生返回值优化。例如：

T foo() { return T(); }

虽然您的情况是这样的：

T pop() {
T temp = stack_storage.front();
stack_storage.erase(stack_storage.begin());
return temp;
}

如您所见，返回对象不是在 return 语句中创建的。
这种情况称为命名返回值优化(NRVO(。

根据该标准，RVO对于编译器是强制性的，而NRVO则不是。

更多关于复制省略的信息。

相关文章：