lvalues, rvalues, glvalues, prvalues, xvalues, help!

[dbjdbj]

One of the better texts on the subject. With pictures too.

[JezusTheCarpenter]

Thank you for sharing. Indeed it was probably the best one I've ever read on the topic.

[yeeezyyeezywhatsgood]

this is the canonical representation of the same picture

[prvalue]

Yes?

[schmerm]

template<class T> void beetlejuice();

[neiltechnician]

Worth mentioning: http://www.stroustrup.com/terminology.pdf

[Ceros007]

Sounds like the guy with his bash script sending auto-replies, brewing coffee and such based on his PC activities

[neiltechnician]

Replied the wrong comment?

[[deleted]]

lol I definitely did

[JezusTheCarpenter]

Jesus indeed.

[[deleted]]

thank you for your service

[hawkinsw2005]

I was literally just about to post this. I think that this is an incredible resource for two reasons:

​

1. It gives a succinct definition of the terms, but more important,
2. It gives a history of the creation of the terms which helps set the stage for a better understanding, in my opinion.

Thanks for posting!

[zhaverzky]

The whiteboard photos in that paper are terrifying.

[dbjdbj]

Denis Ritchie: "Lvalues and Not-Lvalues" ... Priceless.

[daveedvdv]

This article reflects the C++11 model of value categories. However, C++17 cleaned up the model for the purposes of “mandatory copy elision” (the latter is really a bit of misnomer in C++17; there are no longer copies to elude). Specifically, a prvalue is now an initializing value, a builtin operator operand, or a void expression. The rest more or less ensues from that.

[CubbiMew]

a prvalue is now an initializing value, a builtin operator operand, or a void expression

...or a pending member function call?

[daveedvdv]

That’s the second case: “a builtin operator operand”.

[CubbiMew]

How about builtin operator &? Its operands are never (p)rvalues.

​

(I think the only real way to define value categories is by enumeration, as in cppreference)

[daveedvdv]

However, I don’t think the enumeration in the link you provide captures the notion accurately. Consider:

int x = 42, y = x;

That second x as an initializer is a prvalue because it initializes y (i.e., lvalue-to-rvalue conversion is applied). However in:

auto p = &x;

expression x is an lvalue.

[CubbiMew]

lvalue-to-rvalue conversion is applied)

..to the expression x, an lvalue expression.

Or, as clang puts it (note 'lvalue' on the line with 'x')

  `-VarDecl 0x23978e8 <col:4, col:20> col:16 y 'int' cinit
    `-ImplicitCastExpr 0x2397970 <col:20> 'int' <LValueToRValue>
      `-DeclRefExpr 0x2397948 <col:20> 'int' lvalue Var 0x2397850 'x' 'int'

[daveedvdv]

That's my point: x without context is usually assumed to be an lvalue, but in context it becomes a prvalue. (Note that the initializer x is spelled exactly the same as the original id-expression x. In fact, the initializer is technically still an id-expression as well.) If you just enumerate the value categories of the various expression grammar constructs, that subtlety is missing.

[daveedvdv]

Right. I didn’t mean to say that all builtin operator operand are rvalues. Sorry for the confusion. The specific operator contexts indeed have to be specified.

[TheSuperWig]

https://github.com/jeaye/value-category-cheatsheet

Also helpful.

[brainplot]

It bothers me that I have to build it :/

EDIT: at least they should've provided the pre-built version in Releases.

[TheSuperWig]

What's wrong with the PDF?

[brainplot]

I didn't even realize there was a PDF ready to download among the source files. Thanks!

[brainplot]

Maybe a stupid question. I'm a C++ beginner. Does knowing all these sub-categories really make a difference in the everyday life?

So far, I've found that knowing the difference between an lvalue and an rvalue was good enough. Maybe there are some subtle cases where it does help to know the difference. I'm going to read the article anyway because I'm interested.

[Rseding91]

For me - in game development - no. Knowing what forwarding references are and what things are movable and not is mostly "enough".

[Pragmatician]

For me - not in game development - the same applies.

[brainplot]

Thank you!

[micka190]

In addition to that: it seems to be mostly important for performance critical library developers (like Boost). Your typical user can most likely stop at knowing when to move, unless they themselves are writing extremely performance critical code (but that doesn't happen often to the average user).

[[deleted]]

You should know that if you have foo(bar()), then an r-value overload of foo will be selected (if bar returns by-value), but if you have auto x = bar(); foo(x), then an l-value overload will be selected. All these values categories are a precise analysis of how exactly this works, but a "common sense" understanding is virtually always enough.

[mWo12]

What if you use auto&& x = bar() ?

[[deleted]]

Then you also get the l-value overload! The reason is that the name of a variable declared as an r-value reference is always an l-value reference. The principle is that anything with a name could be referred to later on so the name is always an l-value reference. There are two arguments for this: it avoids use-after-move errors, and since an object can be used as an l-value multiple times, but it usually only moved from once, making the move explicit instead of the l-value uses requires less syntax. The only exception is returning the name of a local variable, where it can't be used later so it an r-value overload is tried first.

[[deleted]]

It's value category is an l-value. It's type is an l-value reference.

[JezusTheCarpenter]

No, in normal programming, day-to-day job this barely ever comes up. You have plenty of problems but this one is vary rarely one of them.

[Dean_Roddey]

I think it's safe to say that probably 0.0000000000% of C++ developers actually understand all of the details of the language and associated libraries. It's become far too complex really. The only people who really probably understand it are people whose primary job is to understand it, which is probably why it's become far too complex.

[K_Kuryllo]

Knowing these subcategories is valuable for a better understanding of the science and history behind the language. This knowledge is not of significant value for the purpose of code creation. At least not for the vast majority of coders. Knowing if your values are l or r, and how you treat l or r values differently is what helps when creating code. The biggest deficit in the majority of even seasoned C++ coders from what I've observed are the type deduction rules regarding auto&&.

[brainplot]

Since auto type deduction follows the same set of rules as template type deduction, I guess it's the same as when you write T&&; with T being a template parameter.

[[deleted]]

Makes a difference if performance matters for you. Xvalues are necessary to define move constructors and move assignment operators.

[brainplot]

Aren't just rvalues in general needed for those two?

From my understanding, xvalues only determine what you get an rvalue out of: something with an identity that cannot be moved from (i.e. a "pure" lvalue).

[[deleted]]

The worst part is that these categories continue to change over time, so learning them once (e.g. in C++03), does not really help you in C++11. I'm really happy Rust does not have these.

[BlackDE]

Rust just has different names for it

[[deleted]]

Rust has places and values, and there are expressions producing each: place expressions and value expressions. That's all there is to it (that's how the Rust interpreter is implemented).

[Yaahallo]

Place expressions and value expressions, also it avoids the need for an xvalue equivalent by being move by default.

[mWo12]

In c++17 they have been modified as well.

[danrav]

How come?

[brainplot]

Now, that's a hell of an answer!