Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
blog.knatten.org
Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
1–10 of 94 posts
Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
#2lvalues are locatable, they represent an object that occupies some identifiable location in memory (has address). rvalues do not and therefore cannot be addressed (with & or *)
I think of lvalues as things on the stack and rvalues as things stored in registers
https://eli.thegreenplace.net/2011/12/15/understanding-lvalu...
Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
#3Excellent explanation. Too bad it's necessary. && and std::move are the biggest warts in C++ (that's saying a lot), representing the need for programmers to be constantly aware of the less-than-obvious ways that a compiler might put an expression in one category or another. It's the programmer helping the compiler, instead of the other way around as it should be. In general, if I need an rvalue and it's legal to convert the lvalue I have into an rvalue, the compiler should do it automatically. Having to make it explicit should be the exception, not the rule. The compiler does many other kinds of inference and automatic promotion/conversion, some of them far more difficult (and dangerous). Why not this one? I suspect the reason has less to do with the actual ergonomics of producing correct programs than with the the interests and self-image of those creating the standards.
Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
#4lvalues are locatable, they represent an object that occupies some identifiable location in memory (has address). rvalues do not and therefore cannot be addressed (with & or *) I think of lvalues as things on the stack and rvalues as things stored in registers https://eli.thegreenplace.net/2011/12/15/understanding-lvalu...
The article starts by explaining lvalues and rvalues more precisely than that, and breaks them up into 3 additional value categories in modern C++ (the ones in the title).
(Also, lvalues aren't tied to the stack: they can be anywhere in memory, like heap or static.)
Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
#5lvalues are locatable, they represent an object that occupies some identifiable location in memory (has address). rvalues do not and therefore cannot be addressed (with & or *) I think of lvalues as things on the stack and rvalues as things stored in registers https://eli.thegreenplace.net/2011/12/15/understanding-lvalu...
C99 actually lets you make "pointer literals" (dont know the proper name) by putting an addressof operator in front of rvalue expressions. I cant offer a better explanation than the one you gave, though.
Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
#6Is it totally exactly true that a `glvalue` is either an `xvalue` or a `lvalue` and nothing else?
Similarly, is a `rvalue` either a `xvalue` or a `prvalue`?
Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
#7Excellent explanation. Too bad it's necessary. && and std::move are the biggest warts in C++ (that's saying a lot), representing the need for programmers to be constantly aware of the less-than-obvious ways that a compiler might put an expression in one category or another. It's the programmer helping the compiler, instead of the other way around as it should be. In general, if I need an rvalue and it's legal to conv…
suppose you have a shared ptr and you pass it to a function with overloads for move and value. what should the compiler deduce? it can't tell if it's legal. it can't tell if it's illegal
I agree this is a nasty thing to rely on, but id rather be verbose and know what's happening than have more deduction guides/similar
Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
#8Excellent explanation. Too bad it's necessary. && and std::move are the biggest warts in C++ (that's saying a lot), representing the need for programmers to be constantly aware of the less-than-obvious ways that a compiler might put an expression in one category or another. It's the programmer helping the compiler, instead of the other way around as it should be. In general, if I need an rvalue and it's legal to conv…
> if I need an rvalue and it's legal to convert the lvalue I have into an rvalue, the compiler should do it automatically
What you just said makes no sense. Effectively, you're saying "#yolo, just let the caller function destroy my variables if it feels like it".
> than with the the interests and self-image of those creating the standards
Yeah, you're totes correct, it's a giant conspiracy of smart people to make stupid people feel stupid.
Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
#9Is it totally exactly true that a `glvalue` is either an `xvalue` or a `lvalue` and nothing else? Similarly, is a `rvalue` either a `xvalue` or a `prvalue`?
Yes, section 8.2.1 "Value Category" (page 80) of the C++17 standard[0] defines the terms as:
(1.1) - A glvalue is an expression whose evaluation determines the identity of an object, bit-field, or function.
(1.2) - A prvalue is an expression whose evaluation initializes an object or a bit-field, or computes the value of the operand of an operator, as specified by the context in which it appears.
(1.3) - An xvalue is a glvalue that denotes an object or bit-field whose resources can be reused (usually because it is near the end of its lifetime).
(1.4) - An lvalue is a glvalue that is not an xvalue.
(1.5) - An rvalue is a prvalue or an xvalue.
It also has a diagram summarising it (equivalent to the one in the article, but the article's is clearer IMO):
expression
/ \
glvalue rvalue
/ \ / \
lvalue xvalue prvalue
[0]: available free as a late draft: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n471...
Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)
#10Excellent explanation. Too bad it's necessary. && and std::move are the biggest warts in C++ (that's saying a lot), representing the need for programmers to be constantly aware of the less-than-obvious ways that a compiler might put an expression in one category or another. It's the programmer helping the compiler, instead of the other way around as it should be. In general, if I need an rvalue and it's legal to conv…
suppose you have a shared ptr and you pass it to a function with overloads for move and value. what should the compiler deduce? it can't tell if it's legal. it can't tell if it's illegal I agree this is a nasty thing to rely on, but id rather be verbose and know what's happening than have more deduction guides/similar
If the compiler can't deduce what to do or whether it would be safe then sure, it should require the programmer to disambiguate. The keywords and underlying mechanisms should exist, just as with type casts and such. However, I see a lot of cases where what the intent is obvious and the result obviously safe. Often the compiler even manages to identify the one reasonable answer, but instead of applying it or at least presenting it to the user in readily applicable form it throws an error with the answer converted into standards-ese and surrounded with a dozen lines of irrelevant context. That's not helpful.
I've worked on a lot of large old C codebases, mostly kernels and filesystems. Every one has developed its own way to handle issues of object lifetime, ownership, etc. I've seen dozens of implementations of automatic reference counting, borrowing, weak references, and so on. Some of them have been widely and rightly regarded as awful and a pain to use, but none of them were as bad as the mess that C++ imposes on a much larger audience. I see a lot of my colleagues submit to Stockholm Syndrome and accept it as the proper way of the world, but I'm not inclined to follow their lead without registering my objections first.