Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)

https://blog.knatten.org/2018/03/09/lvalues-rvalues-glvalues-prvalues-xvalues-help/

by signa11 • 7 years ago

246 92 7 years ago

blog.knatten.org

lvalues 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...

dbaupp5• 7 years ago

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.)

leetcrew3• 7 years ago

how can you have an lvalue stored in the heap? isn't the lvalue itself a pointer in the stack? obviously I see how it can have static storage.

jstimpfle• 7 years ago

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.

quietbritishjim• 7 years ago

rvalues do not and therefore cannot be addressed (with & or *)

Correction: prvalues cannot be addressed. There are also xvalues, which are both rvalues and lvalues i.e. they can be addressed but can also be moved from. In practice I think these are always lvalues that have been cast to an rvalue reference, usually using std::move().

mannykannot3• 7 years ago

This thread is recapitulating the article.

twic• 7 years ago

I used to think that. It's simple, right? Then i said so on the C++ Slack and got the hell beaten out of me. In modern C++, lvalue and rvalue simply don't mean what they do in other languages. Wild but true.

ncmncm9• 7 years ago

Lvalue and rvalue are inventions that serve a particular purpose in Algol-family languages. They are not physics.

These other value categories are further inventions for additional purposes. The only unfortunate bit is the insistence on one-letter abbreviations when discussing them.

notacoward16• 7 years ago

Excellent 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.

xhgdvjky• 7 years ago

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

notacoward16• 7 years ago

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.

daoxid• 7 years ago

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.

This is already done in some places. Example:

    std::unique_ptr<int> get_int() {
        auto p = std::make_unique<int>(1);

        // `p` is an lvalue but treated as an rvalue in the return statement.
        // (This would not compile otherwise because `p` is not copyable.)
        return p;
    }

notacoward16• 7 years ago

That is the right approach IMO. What I'm basically saying is "more of this". It's clearly possible for C++ compilers to do this in many more cases. They already do most of the hard parts just to produce some of the error messages that they do. Why not use that knowledge more often to help the programmer instead of burdening them?

woud420• 7 years ago

Yes RVO is one case where the compiler will do it automatically.

I think copy initialization of an object will have the same will apply copy elision as well to result in the same performance, but I'm not entirely sure.

dataflow• 7 years ago

It's not what what you're asking is unreasonable in concept, but that it goes against how RAII is used in C++; it'd make more sense in a new language. Specifically the issue is that despite its name, RAII isn't merely used for resource acquisition, but also to define dynamic scopes. That means destroying an object too early (which can happen if an object is automatically moved) can cause a subsequent statement that doesn't syntactically depend on the variable holding that object to see the wrong program state. So if your compiler moved objects automatically, that'd break code that uses RAII as a dynamic scoping mechanism.

That said though, it might be cool to have an [[attribute]] for classes (maybe [[automove]]? or [[resource]]? or [[functional]] or [[dataflow]]??) that lets you declare that that a class's construction and destruction (or maybe all members... ) can be assumed to have no side-effects for clients to depend on, or something like that... if they can work it out that'd be cool. Ideally it'd mean that an automatic variable of that type can be destroyed following its last dependency in any given scope.

notacoward16• 7 years ago

it goes against how RAII is used in C++

That's an excellent point. To be honest, I think it's a problem with how RAII is used, conflating execution scope and object lifetime in a way that makes "move" a bit of a mess. That's why I prefer explicit "defer" like some languages have. Nonetheless, it's a common and useful enough idiom that breaking it is not something to be taken lightly. Maybe it's not really a solvable problem, given the paths that C++ took years ago, but I'd say "too bad it's necessary" is even more applicable if that's the case.

Rusky5• 7 years ago

Automatic moves don't imply that you can't use RAII to define dynamic scopes. In fact it's the reverse- moves give RAII much more power and flexibility around scopes. The problem, instead, is that C++ has no way to determine whether later statements depend on moved-from variables.

To a first approximation, this could be solved using the same analysis that powers "use of uninitialized variable warnings." In the general case you need something more powerful, like the C++ Core Guidelines lifetime checker (https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...). This means move operations end scopes just like `}`s do, preserving both RAII and the compiler's ability to help the programmer.

FrankHB2• 7 years ago

Dynamic scopes are not available in C++. I suppose them as in languages like Emacs Lisp. I get the point, though.

jlebar• 7 years ago

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?

How do you even tell that it's legal to stick std::move around a variable? Here's a really simple example.

void test() { std::string s = ...; foo(s); bar(s); }

Can I change the last line to bar(std::move(s))? I can write a well-formed program that will misbehave, perhaps something like

char* global; void foo(const std::string& s) { global = s.data(); }

void bar(const std::string& s) { assert(global == s.data()); }

(Note that s.data() is not necessarily unchanged after std::move'ing the object, due to small-string optimization.)

This is contrived, but my point is that this is really tricky to do automatically.

Note also that when adding rvalue references the language committee had the additional constraint of not breaking existing programs. This makes things like automatic inference of temporariness even trickier.

The compiler does many other kinds of inference and automatic promotion/conversion, some of them far more difficult (and dangerous).

The C++ compiler does exceptionally few transformations that can change the behavior of a well-formed program. In fact, the only one that comes to mind is copy elision (aka RVO).

notacoward16• 7 years ago

The C++ compiler does exceptionally few transformations that can change the behavior of a well-formed program.

So all of those conversions between numeric, pointer, or string-ish types are just figments of my imagination? The rules for which constructor to use, which template or overload to apply, aren't a form of inference? "Auto" doesn't exist? Maybe there's some class of transformations and some definition of "well formed" for which your statement is true, but I can't imagine what those are.

FrankHB2• 7 years ago

This is simply not acceptable because it would silently break too much code. Parameter passing in C++ used to mean copy, not move.

Perhaps a more important rule is that id-expressions should mean lvalues, not xvalues. Note that even expressions of rvalue references are not xvalues in such contexts. So, making something to-be-moved visually different from others is quite intentional.

Alternatively, to prevent use-after-move cases by additional syntaxes with typechecking rules (like Rust) can be a good idea, but it also does not work here. And C++ still lacks destructive move. (Note this has been considered at the very beginning of the design. Sadly it does not easily interact well with other features. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n137...)

rocqua2• 7 years ago

Is 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`?

dbaupp5• 7 years ago

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

Where every expression is in one of the three value categories in the bottom row.

[0]: available free as a late draft: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n471...

rocqua2• 7 years ago

Thanks, I actually recall seeing that diagram.

I agree that the article is clearer. Because I didn't get it when I saw that diagram, but I do get it after reading the article.

meuk• 7 years ago

Articles like this make me feel very smug about my decision never to go down the rabbithole of learning C++.

I feel perfectly comfortable with using pointers (and my intuition about them) in C.

chubot• 7 years ago

FWIW I mostly use “out params” as in C because I think moves incur a lot of complexity, as well explained in this article. It’s also more lines of code to write. Some people may quibble with it but I think it’s still a fine style of writing C++, and in fact most C++ you’ll see is written like that, since this is a new-ish feature.

strictfp• 7 years ago

Agreed. RVO is not guaranteed, and move is complex. Smart pointers have overhead. Out params are for the most part a sensible choice in C++. Sadly. I'm honestly shocked that this problem hasn't been addressed in a better way.

tomnj• 7 years ago

C++ is for sure extremely complicated, but I’d argue that a full understanding of value categories (glvalues, xrvalues, etc) isn’t necessary to be productive with the language.

xsmasher• 7 years ago

I spent five years in the C++ mines, and spooky corners and edge cases and arcane rules like this made me happy to leave.

Working in a language where I can be concerned with the task and hand and not ownership issues is refreshing.

userbinator• 7 years ago

To me, knowing C++, especially the "modern" dialect, is good for job security but like you I prefer plain old C for everything else.

bagol• 7 years ago

Is this concept of lvalues, rvalues, glvalues, prvalues and xvalues only exists in C++?

Sharlin• 7 years ago

Few other languages have move semantics. Rust does, but has a quite different value model overall.

cesarb• 7 years ago

Also, Rust does not have copy or move constructors/operators; every copy or move is a pure memcpy() (there's Clone for when you need it, but clone is always an explicit call). This simplifies the model a lot.

steveklabnik2• 7 years ago

Our equivalent to lvalue/rvalue is “place expression” and “value expression” https://doc.rust-lang.org/reference/expressions.html#place-e...

mjn• 7 years ago

lvalue/rvalue are old concepts and terms ('60s/'70s) and common to all C-family languages. The others are new to C++.

Jeaye• 7 years ago

Similarly, the value category cheatsheet: https://github.com/jeaye/value-category-cheatsheet/blob/mast... and more info on xvalues: https://blog.jeaye.com/2017/03/19/xvalues/

agallego• 7 years ago

great post!

contravariant• 7 years ago

Maybe this is just naive / wishful thinking, but wouldn't it have made way more sense to go with either:

glvalues, lvalues, grvalues, rvalues, xvalues

lvalues, plvalues, rvalues, prvalues, xvalues

Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)

Related Stories