News for hackers. Stuff that matters.

A comment on Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018). Parent comment

Re:Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018) by dbaupp on Thursday April 11, 2019 @09:48AM (#19634451)
If foo is an lvalue, then I believe (for example)

   *(foo[0].bar->baz)
is also an lvalue, and those pointer dereferences can go anywhere. Those values occupy a location in memory, as you said, even if it isn't on the stack.
[ Parent | on HN ]
Re:Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018) by leetcrew on Thursday April 11, 2019 @10:12AM (#19634699)
oh okay, understood. frankly I don't have an airtight understanding of the c++ standards and I would have considered your expression to be a dereference operation on an lvalue, but not an lvalue itself. ty for the explanation!
[ Parent | on HN ]
Re:Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018) by simiones on Thursday April 11, 2019 @10:27AM (#19634840)
I'm sure there are some complex exceptions, but as a starter, you can think of lvalues as "anything you can assign to" (the l basically stands for left, as in, "can appear on the left of an assignment"). So, if you have something like `foo(val) = 10`, then `foo(val)` is an lvalue.
[ Parent | on HN ]
Re:Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018) by mannykannot on Thursday April 11, 2019 @11:07AM (#19635232)
One of the complications is that if you take an l-value and const-qualify it, it is still an l-value (but not a modifiable l-value.)

https://www.geeksforgeeks.org/lvalue-and-rvalue-in-c-languag...

[ Parent | on HN ]
Re:Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018) by mannykannot on Thursday April 11, 2019 @11:01AM (#19635139)
They are not mutually exclusive. When a pointer has been set to point to an lvalue, dereferencing it yields that lvalue.
[ Parent | on HN ]