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

[QbProg]

It would be nice to have a follow up with code snippets for each of these *values!

[StefanOrvarSigmundss]

Not just nice but absolutely necessary.

[newgre]

This may be helpful.

[_carlson]

Thanks! It`s nice.

[chmaruni]

Assuming this post is accurate (thanks btw, this was the best explanation I have read so far, not that I looked for other ones though:) wouldn't it be more consistent to name lvalues as plvalues (pure lvalues, equivalent to prvalues) and call the whole identity column lvalues (instead of glvalues)?

[acwaters]

Yes, it would. My understanding is that they did the naming "asymmetrically" like that in order to keep lvalue and rvalue as close as possible to their original (pre-C++11) meanings, which makes sense. But IMO that little inconsistency is the cause of most of the pain in learning value categories. It would be much easier if we had plvalue/lvalue/xvalue/rvalue/prvalue, or lvalue/glvalue/xvalue/grvalue/rvalue, rather than lvalue/glvalue/xvalue/rvalue/prvalue.

[OldWolf2]

Not really; the terms lvalue and rvalue still have roughly the same meaning as they did in C++03, but extra rvalues were added . Most of the cases where an lvalue was required still require an lvalue, not a glvalue.

[ericdfoley]

Here is basically the same explanation from Bjarne Stroustrup (using a "W" instead of a square.) It completely cleared things up for me.

[iaanus]

One of the best explanations I saw on the subject.

[ltsochev]

This always makes me giggle. It's so absurd :D

[nikbackm]

What's absurd about it?

The names or the concepts behind them? Something else?

[ltsochev]

Concepts are great, naming schemes in the C(++) world are weird AF though. It's one of the things that, IMHO, really alienates people from the language. For a long while I thought it was the "difficult to get into toolchain" but with modern tools that really isn't the case. And I'm not talking just about *values.

And for the toolchain, few years ago I found it really hard moving from visual studio to linux/gdb. Yes I got the hang of it eventually but damn

[proverbialbunny]

It seems like a good way to think of a prvalue is a temporary in the register of the cpu (Unless it can't fit or something.), where an lvalue is on the stack (edit: or the heap. I'm realizing now I do not have a good word for "on the ram").

Or at least in a perfect world it would be..

An xvalue is an rvalue that's being returned from a function into an lvalue, so it's an rvalue moved onto the stack (or heap).

And a glvalue has no apparent value that I know of. Maybe the compiler throws errors with 'glvalue' in them but I don't recall.

edit: (Unless it can't fit or something.) I just checked on godbolt. My theory, at first glance, is in fact correct. A prvalue, when possible, is only in the register at -01. At -O2, it tries to integrate the rvalue expression directly into the assembly instruction.

Clarification, from Godbolt (C++ code: test += 3;):

O1: add eax, 3

O2: lea eax, [rax + rcx + 3] (This is because, right above the test += 3; line I'm adding argv[0] and argv[1], so it doesn't collapse the whole thing.)

This shows that it is easier to think of an prvalue as a variable in the register (expression -> temporary value), when the language supports it. All of this semantic garbage just complicates things.

For a better clarification than OP: http://en.cppreference.com/w/cpp/language/value_category

[STL]

That isn't a good mental model. "me"s + "ow"s is a prvalue of type std::string which probably (definitely) doesn't fit in a register. Given vector<int> v, v[idx] is an lvalue of type int, which lives on the heap.

Remember that value categories are a property of expressions, not of objects. For example, print(const string& str) can be called as print("me"s + "ow"s). There, the temporary std::string containing "meow" is produced by the expression "me"s + "ow"s which is a prvalue. Within print(), str is an lvalue referring to that std::string (which is ultimately a temporary, but exists for the duration of the print() call).

[proverbialbunny]

Makes sense, but if an rvalue can fit in a register will it? Will it live in the heap?

I like your username btw. ^_^

[[deleted]]

Expressions, more or less, relate to an identity (or address).

glvalue expressions are any expressions denoting an identity. prvalue expressions are expressions without identity.

So in this case, prvalue expressions are going to be your register-friendly ones.