问题标签 [rvalue-reference]

下一个 c++ 标准中即将出现的 R-Value 参考是什么？

例如：

假设我有一个功能：

C++0x 是否明确表示将避免 randomVector 的返回值中的虚假副本？或者编译器是否需要实现 RVO？在我看来，该值randomVector()应该被视为右值，因此应该调用 v 的移动构造函数，但我不完全确定这是真的。

std::move在 C++11 中，当我们想要将值移动（破坏性复制）到容器中时，我们可以通过使用来提高效率：

但我找不到任何相反的方向。我的意思是这样的：

这在适配器的 like 上更频繁（复制弹出）stack。这样的事情是否存在：

避免复制？这已经存在了吗？我在n3000中找不到类似的东西。

我有一种感觉我错过了一些非常明显的东西（比如它的不必要性），所以我为“ru dum”做好了准备。:3

§3.10 第 9 节说“非类右值总是有 cv 非限定类型”。这让我想知道...

根据标准，非类类型没有 const rvalue 这样的东西，但bar()更喜欢绑定到const int&&. 这是编译器错误吗？

编辑：显然，this也是一个 const rvalue :)

编辑：这个问题似乎在 g++ 4.5.0 中得到修复，现在两行都打印“rvalue”。

第一：在哪里std::move定义std::forward？我知道他们做了什么，但我找不到任何标准标题都需要包含它们的证据。在 gcc44 中有时std::move可用，有时不可用，因此明确的包含指令会很有用。

在实现移动语义时，源可能处于未定义状态。该状态是否必须是对象的有效状态？显然，您需要能够调用对象的析构函数，并且能够通过类公开的任何方式分配给它。但是其他操作应该有效吗？我想我要问的是，如果你的类保证某些不变量，当用户说他们不再关心它们时，你是否应该努力强制执行这些不变量？

下一步：当您不关心移动语义时，在处理函数参数时，是否有任何限制会导致非常量引用优于右值引用？ void function(T&);从void function(T&&);调用者的角度来看，能够传递函数临时值有时很有用，因此似乎只要可行，就应该授予该选项。并且右值引用本身就是左值，因此您不能无意中调用移动构造函数而不是复制构造函数或类似的东西。我看不出有什么缺点，但我敢肯定有一个缺点。

这让我想到了我的最后一个问题。您仍然不能将临时对象绑定到非常量引用。但是您可以将它们绑定到非常量右值引用。然后，您可以将该引用作为非常量引用传递给另一个函数。

除了它什么都不做之外，该代码有什么问题吗？我的直觉说当然不是，因为更改右值引用是它们存在的全部意义。如果传递的值是合法的 const，编译器会捕捉到它并对你大喊大叫。但从表面上看，这是一种机制的变通，可能是出于某种原因而实施的，所以我只想确认我没有做任何愚蠢的事情。

我最近安装了 Visual Studio 2010 Professional RC 来试用并测试在 VC++ 2010 中实现的几个 C++0x 功能。

我实例化了一个std::vector，std::unique_ptr没有任何问题。但是，当我尝试通过将临时对象传递给 来填充它时push_back，编译器会抱怨 的复制构造函数unique_ptr是私有的。我尝试通过移动它来插入一个左值，它工作得很好。

事实证明，问题既不在于，unique_ptr也不vector::push_back在于 VC++ 在处理右值时解决重载的方式，如以下代码所示：

编译器抱怨无法访问复制构造函数。如果我将其公开，则程序将编译（即使未定义复制构造函数）。

我是否误解了有关右值引用的某些内容，或者它是 VC++ 2010 实现此功能的一个（可能已知的）错误？

不编译...（说 unique_ptr 的复制构造函数被删除）

我尝试用前进替换移动。不确定我是否做得对，但它对我不起作用。

我正在添加新的运算符重载以利用 c++0x 右值引用，并且我觉得我正在生成大量冗余代码。

我有一个类，tree它包含一个对双值的代数运算树。这是一个示例用例：

对于每个二元运算（如加号），每一边都可以是左值tree、右值tree或double. 这导致每个二元操作有 8 个重载：

对于每个二元运算（减、乘、除等），也必须以某种方式重复。

如您所见，我实际上只需要编写 4 个函数；其他 4 个可以转换并转发到核心案例。

您对减小此代码的大小有什么建议吗？

PS：这个类实际上比一个双打树更复杂。减少副本确实显着提高了我的项目的性能。所以，右值重载对我来说是值得的，即使有额外的代码。我怀疑可能有一种方法可以将上面的“cast and forward”案例模板化，但我似乎想不出任何东西。

（我在 comp.std.c++ 上问了这个问题的一个变体，但没有得到答案。）

为什么f(arg)此代码中的调用调用 const ref 重载f？

我的直觉说f(string &&)应该选择重载，因为arg无论如何都需要将其转换为临时值，并且临时值比右值引用更好地匹配右值引用。

这不是在GCC 和MSVC 中发生的（编辑：感谢 Sumant：它不会在 GCC 4.3-4.5 中发生）。至少在G++ 和MSVC 中，任何左值都不会绑定到右值引用参数，即使创建了中间临时值也是如此。实际上，如果不存在 const ref 重载，编译器会诊断出错误。但是，如您所料，编写f(arg + 0) orf(std::string(arg)) 确实选择了右值引用重载。

从我对 C++0x 标准的阅读来看，在考虑是否可行时，似乎应该考虑将 const char * 隐式转换为字符串f(string &&)，就像传递 const lvalue ref 参数时一样。第 13.3 节（重载解决方案）在太多地方没有区分右值引用和 const 引用。此外，如果存在中间临时对象，阻止左值绑定到右值引用 (13.3.3.1.4/3) 的规则似乎不应该适用——毕竟，从临时对象中移出是完全安全的。

这是：

1. 我误读/误解了标准，其中实现的行为是预期的行为，并且有一些很好的理由说明我的示例应该按照它的方式运行？
2. 编译器供应商都犯了一个错误？还是基于常见实施策略的错误？或者例如 GCC 中的一个错误（这个左值/右值引用绑定规则是第一次实现的），被其他供应商复制了？
3. 标准中的缺陷，或意外后果，或应该澄清的东西？

编辑：我有一个相关的后续问题：C++0x rvalue references - lvalues-rvalue binding