这些新类别与现有的右值和左值类别有何关联？

C++03左值仍然是C++11左值，而C++03右值在C++11中称为prvalue。

这是我为我正在写的一本高度可视化的C++书制作的Venn图，我很快将在开发期间在leanpub上发布这本书。

其他答案用文字更详细，并显示类似的图表。但希望这些信息的介绍是相当完整的，并且对参考也很有用。

在这个主题上，我的主要收获是表达式具有这两个财产：身份和可动性。第一个涉及事物存在的“坚固性”。这一点很重要，因为C++抽象机被允许并鼓励通过优化来积极地更改和压缩代码，这意味着没有身份的东西可能只会在编译器或寄存器中存在片刻，然后才会被践踏。但是，如果你回收它的内部，这样的数据也保证不会引起问题，因为没有办法尝试使用它。因此，移动语义被发明出来，允许我们捕获对临时变量的引用，将其升级为lvalues并延长其寿命。

移动语义最初不仅仅是为了浪费时间，而是为了让它们可以被其他人使用。

当你把你的玉米面包送人时，你送人的人现在拥有它。他们会吃掉它。一旦你送人，你不应该试图吃或消化这些玉米面包。也许玉米面包本来是往垃圾堆里去的，但现在是往他们的肚子里去了。它不再是你的了。

在C++领域，“消耗”资源的想法意味着资源现在归我们所有，因此我们应该进行任何必要的清理，并确保对象不会在其他地方访问。通常情况下，这意味着借用勇气来创建新对象。我称之为“捐献器官”。通常，我们讨论的是对象中包含的指针或引用，或者类似的东西，我们希望保留这些指针或引用的位置，因为它们引用的是程序中其他未消亡的数据。

因此，您可以编写一个接受rvalue引用的函数重载，如果传入了临时（prvalue），则将调用该重载。一个新的左值将在绑定到函数所取的右值引用时创建，从而延长临时值的寿命，以便您可以在函数中使用它。

在某一时刻，我们意识到，我们经常会在一个范围内处理完左值非临时数据，但却希望在另一个范围中进行分解。但它们不是右值，因此不会绑定到右值引用。所以我们做了std:：move，这只是一个从左值到右值引用的花式转换。这样的数据是一个xvalue：一个以前的lvalue，现在就像它是一个临时的，所以它也可以从中移动。

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

为什么需要这些新类别？

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
}

IMHO，关于其含义的最佳解释给了我们Stroustrup+考虑到Dániel Sándor和Mohan的例子：

斯特鲁斯特鲁普：

现在我非常担心。显然，我们正在走向僵局，或者一团糟或两者兼而有之。我用午餐时间做了一个分析，看看（值的）财产是独立的。只有两个独立财产：具有标识–即地址、指针，用户可以确定两个副本是否相同等。可以从中移动–即，我们可以以某种不确定但有效的状态离开到“副本”的源这使我得出结论：值（使用正则表达式符号技巧，使用大写字母表示否定——我很着急）：iM：具有标识，无法从中移动im：具有身份并且可以从中移动（例如，将左值转换为右值引用的结果）Im：没有身份，可以被转移。第四种可能性是IM（没有身份，无法移动）在C++（或者，我认为）任何其他语言中都很有用。除了这三种基本的价值分类，我们有两个明显的概括，与这两个相对应独立财产：i： 具有身份m： 可以从移动这让我把这张图放在黑板上：命名我观察到，我们只有有限的命名自由：左边（标记为iM和i）是人们或多或少拥有的形式称为lvalues和右边的两点（标记为m和Im）是多少有些拘谨的人称为右值。这必须反映在我们的命名中。即，W的左“腿”应具有与左值和W的右“腿”应该有和右值相关的名称。我注意到了整个讨论/问题源于右值引用和移动语义。这些概念根本不存在在Strachey的世界中，只有右值和左值。某人观察到每个值都是左值或右值左值不是右值，右值不是左值深深嵌入我们的意识，非常有用的财产，以及在整个标准草案中都可以找到这种二分法的痕迹。我们所有人都同意我们应该保留那些财产（并使其精确）。这进一步限制了我们的命名选择。我观察到标准库措辞使用rvalue表示m（概括），以便保留标准库W的右下点应命名为右值。这导致了对命名的集中讨论。首先，我们需要决定左值。左值是指iM还是广义i？带路道格·格雷戈，我们列出了核心语言措辞中的位置其中lvalue一词被限定为表示一个或另一个。A.在大多数情况下，在最棘手/最脆弱的文本中列出了列表lvalue当前表示iM。这是左值的经典含义因为“在过去的日子里”，什么都没有动过；这是一个新颖的概念在C++0x中。此外，命名左上角的W值给了我们每个值都是左值或右值，但不是两者都是。所以，W的左上角是左值，右下角是为右值。左下角和右上角是什么？左下点是经典左值的推广，允许移动。所以它是一个广义的左值。我们给它取名glvalue值。你可以对缩写词吹毛求疵，但（我认为）不行逻辑。我们假设在认真使用广义左值无论如何都会被缩写，所以我们最好这样做立即（或风险混淆）。W的右上角较小一般比右下角（现在，一如既往，称为右值）。那个点表示可以移动的对象的原始纯概念因为它不能再次引用（析构函数除外）。我喜欢专门的右值这个短语，而不是广义的右值lvalue，但缩写为prvalue的纯rvalue胜出（和可能是正确的）。因此，W的左腿是左值glvalue和右腿是prvalue和rvalue。顺便提一句每个值都是glvalue或prvalue，但不是两者都是。这将留下W:im；也就是说并且可以移动。我们真的没有任何指导我们为那些神秘的野兽取了个好名字。它们对使用（草案）标准文本的人员，但不太可能成为家喻户晓的名字。我们没有在命名来指导我们，所以我们选择了“x”作为中心，未知奇怪，只有专家，甚至是x级。

由于前面的答案详尽地涵盖了价值类别背后的理论，我想补充一点：你可以实际使用并测试它。

对于值类别的一些实际实验，可以使用decltype说明符。它的行为明确区分了三个主要值类别（xvalue、lvalue和prvalue）。

使用预处理器可以节省我们一些键入。。。

主要类别：

#define IS_XVALUE(X) std::is_rvalue_reference<decltype((X))>::value
#define IS_LVALUE(X) std::is_lvalue_reference<decltype((X))>::value
#define IS_PRVALUE(X) !std::is_reference<decltype((X))>::value

混合类别：

#define IS_GLVALUE(X) (IS_LVALUE(X) || IS_XVALUE(X))
#define IS_RVALUE(X) (IS_PRVALUE(X) || IS_XVALUE(X))

现在，我们可以（几乎）复制值类别上cppreference中的所有示例。

以下是C++17的一些示例（用于简洁的static_assert）：

void doesNothing(){}
struct S
{
    int x{0};
};
int x = 1;
int y = 2;
S s;

static_assert(IS_LVALUE(x));
static_assert(IS_LVALUE(x+=y));
static_assert(IS_LVALUE("Hello world!"));
static_assert(IS_LVALUE(++x));

static_assert(IS_PRVALUE(1));
static_assert(IS_PRVALUE(x++));
static_assert(IS_PRVALUE(static_cast<double>(x)));
static_assert(IS_PRVALUE(std::string{}));
static_assert(IS_PRVALUE(throw std::exception()));
static_assert(IS_PRVALUE(doesNothing()));

static_assert(IS_XVALUE(std::move(s)));
// The next one doesn't work in gcc 8.2 but in gcc 9.1. Clang 7.0.0 and msvc 19.16 are doing fine.
static_assert(IS_XVALUE(S().x)); 

一旦你确定了主要类别，混合类别就有点无聊了。

有关更多示例（和实验），请查看编译器资源管理器上的以下链接。不过，不要费心阅读汇编。我添加了很多编译器，只是为了确保它能在所有常见的编译器中运行。

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

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

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

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

引用n3055：

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

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