在C++03中,表达式要么是右值,要么是左值。

在C++11中,表达式可以是:

右值左值x值glvalue值prvalue值

两个类别变成了五个类别。

这些新的表达类别是什么?这些新类别与现有的右值和左值类别有何关联?C++0x中的右值和左值类别是否与C++03中的相同?为什么需要这些新类别?WG21众神只是想迷惑我们这些凡人吗?


当前回答

我想这份文件可以作为一个不那么简短的介绍:n3055

整个屠杀从移动语义开始。一旦我们有了可以移动而不可复制的表达式,突然间,容易掌握的规则要求区分可以移动的表达式和方向。

根据我根据草案的猜测,r/l值的区别保持不变,只有在移动的情况下才会变得混乱。

他们需要吗?如果我们想放弃新功能,可能不会。但为了实现更好的优化,我们可能应该接受它们。

引用n3055:

左值(历史上,因为lvalues可能出现在作业的左侧表达式)指定函数或一个物体。[示例:如果E是指针类型的表达式,则为*E是一个左值表达式,引用E所针对的对象或功能点。作为另一示例调用函数的结果返回类型是左值引用左值。]x值(An“eXpiring”值)也指对象,通常在其末端附近生命周期(以便其资源可以例如被移动)。x值为某些类型的结果涉及右值的表达式参考文献。[示例:调用函数的结果返回类型为右值引用为x值。]glvalue(“广义”左值)是左值或x值。右值(所谓,历史上,因为rvalues可以显示在赋值表达式)是xvalue,临时对象或子对象,或其值不与对象关联。A.prvalue(“纯”右值)是右值这不是xvalue。[示例:调用函数的结果返回类型不是引用是prvalue(压力值)]

所讨论的文件是这个问题的一个很好的参考,因为它显示了由于引入新的命名法,标准发生的确切变化。

其他回答

这些是C++委员会用来在C++11中定义移动语义的术语。这就是故事。

我发现很难理解这些术语,因为它们有精确的定义、长长的规则列表或这个流行的图表:

在带有典型示例的Venn图上更容易:

基本上:

每个表达式都是左值或右值必须复制左值,因为它具有标识,所以可以稍后使用可以移动rvalue,因为它是临时的(prvalue)或显式移动的(xvalue)

现在,好问题是,如果我们有两个正交的财产(“有恒等式”和“可以移动”),那么完成左值、xvalue和prvalue的第四个类别是什么?这将是一个没有标识的表达式(因此以后无法访问),并且无法移动(需要复制其值)。这根本没用,所以没有命名。

我将从你的最后一个问题开始:

为什么需要这些新类别?

C++标准包含许多处理表达式的值类别的规则。有些规则区分左值和右值。例如,当涉及到过载解决方案时。其他规则区分glvalue和prvalue。例如,可以有一个glvalue具有不完整或抽象类型,但没有prvalue具有不完全或抽象类型。在我们使用这个术语之前,实际上需要区分glvalue/prvalue的规则称为lvalue/rvalue,它们要么是无意中错误的,要么包含大量对规则的解释和例外“……除非rvalue是由于未命名的rvalue引用……”。因此,只给glvalues和prvalues的概念起自己的名字似乎是个好主意。

这些新的表达类别是什么?这些新类别与现有的右值和左值类别有何关联?

我们仍然有与C++98兼容的术语lvalue和rvalue。我们将右值分为两个子组,xvalue和prvalue,我们将左值和xvalue称为glvalue。Xvalues是未命名右值引用的一种新的值类别。每个表达式都是这三个值之一:lvalue、xvalue、prvalue。Venn图如下所示:

    ______ ______
   /      X      \
  /      / \      \
 |   l  | x |  pr  |
  \      \ /      /
   \______X______/
       gl    r

函数示例:

int   prvalue();
int&  lvalue();
int&& xvalue();

但也不要忘记,命名的rvalue引用是lvalues:

void foo(int&& t) {
  // t is initialized with an rvalue expression
  // but is actually an lvalue expression itself
}

上面优秀答案的一个补充,即使在我读过Stroustrup并认为我理解了右值/左值的区别之后,这一点也让我感到困惑。当你看到

int&&a=3,

将int&&作为一种类型阅读,并得出a是一个右值的结论是非常诱人的。它不是:

int&& a = 3;
int&& c = a; //error: cannot bind 'int' lvalue to 'int&&'
int& b = a; //compiles

a有一个名字,实际上是一个左值。不要将&&视为a;类型的一部分;它只是告诉你什么是允许绑定的。

这对构造函数中的T&&类型参数尤为重要。如果你写

Foo::Foo(T&&_T):T{_T}{}

你将把t复制到t中。你需要

Foo::Foo(T&&_T):T{std::move(_T)}{}如果您想移动。如果我忽略了移动,编译器会警告我吗!

我想这份文件可以作为一个不那么简短的介绍:n3055

整个屠杀从移动语义开始。一旦我们有了可以移动而不可复制的表达式,突然间,容易掌握的规则要求区分可以移动的表达式和方向。

根据我根据草案的猜测,r/l值的区别保持不变,只有在移动的情况下才会变得混乱。

他们需要吗?如果我们想放弃新功能,可能不会。但为了实现更好的优化,我们可能应该接受它们。

引用n3055:

左值(历史上,因为lvalues可能出现在作业的左侧表达式)指定函数或一个物体。[示例:如果E是指针类型的表达式,则为*E是一个左值表达式,引用E所针对的对象或功能点。作为另一示例调用函数的结果返回类型是左值引用左值。]x值(An“eXpiring”值)也指对象,通常在其末端附近生命周期(以便其资源可以例如被移动)。x值为某些类型的结果涉及右值的表达式参考文献。[示例:调用函数的结果返回类型为右值引用为x值。]glvalue(“广义”左值)是左值或x值。右值(所谓,历史上,因为rvalues可以显示在赋值表达式)是xvalue,临时对象或子对象,或其值不与对象关联。A.prvalue(“纯”右值)是右值这不是xvalue。[示例:调用函数的结果返回类型不是引用是prvalue(压力值)]

所讨论的文件是这个问题的一个很好的参考,因为它显示了由于引入新的命名法,标准发生的确切变化。

C++03的类别太有限,无法将右值引用正确引入表达式属性。

随着它们的引入,据说未命名的右值引用求值为右值,因此重载解析将倾向于右值引用绑定,这将使其选择移动构造函数而不是复制构造函数。但研究发现,这会导致各种问题,例如动态类型和限定。

要显示这一点,请考虑

int const&& f();

int main() {
  int &&i = f(); // disgusting!
}

在xvalue之前的草稿中,这是允许的,因为在C++03中,非类类型的rvalue永远不会被cv限定。但const适用于右值引用情况,因为这里我们确实引用了对象(=内存!),从非类右值中删除const主要是因为没有对象。

动态类型的问题具有相似的性质。在C++03中,类类型的右值有一个已知的动态类型——它是该表达式的静态类型。因为要以另一种方式实现,您需要引用或解引用,它们的计算结果为左值。对于未命名的右值引用,情况并非如此,但它们可以显示多态行为。为了解决这个问题,

未命名的右值引用变为xvalue。它们可以是限定的,并且可能具有不同的动态类型。它们确实像预期的那样,在重载期间更喜欢右值引用,并且不会绑定到非常值左值引用。以前是一个rvalue(文本,通过对非引用类型的强制转换创建的对象)现在变成了一个prvalue。在重载期间,它们与xvalue具有相同的偏好。以前的左值仍然是左值。

我们进行了两个分组,以捕获那些可以被限定并且可以具有不同动态类型(glvalue)的对象,以及那些重载更喜欢右值引用绑定(rvalues)的对象。