Definition of lvalue/rvalue
Hendrik Schober
as a second job I am teaching C++. I have only 3-4 months to
teach it to students who had two semesters of exposure to
Java.
What I have learned doing this is that I need to find concise
definitions for everything I want them to remember. Sometimes
such definitions are surprisingly hard to find.
One of the problems I keep running into is finding a good
answer to the question "What's an lvalue/rvalue?" I have asked
for a concise definition for this in newsgroups several times
and searched the archives for other discussions of the topic,
so I know impossible to come up with an easy definition. Yet I
really do need to come up with a definition myself that needs
to be simple enough to be remembered by my students while still
being correct. (This will become even more urgent once rvalue
references will become available.)
So is there any short enough description this groupd can come
up with?
TIA,
Schobi
--
Spam...@gmx.de is never read
I'm HSchober at gmx dot de
"The trouble with being a god is that you've got
no one to pray to." Terry Pratchett
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Martin York
> Hi,
>
> as a second job I am teaching C++. I have only 3-4 months to
> teach it to students who had two semesters of exposure to
> Java.
>
> answer to the question "What's an lvalue/rvalue?"
Simple (but not too simplistic) and easy to remember
=====================================================
lvalue: an expression that can be placed on the left hand side of an
assignment.
rvalue: an expression that can be placed on the right hand side of an
assignment.
Note: rvalue can NOT go on the left because they are basically read
only.
Note: lvalue CAN go on both sides (if you can write to it you can read
it).
--
restor
http://groups.google.co.uk/group/comp.std.c++/browse_thread/thread/ec79707a128de78d/5cffdaed89370523?hl=en&lnk=st&q=#5cffdaed89370523
The view emerging from the discussion was that the description of
lvalue/rvalue can be either precise or short, but not both. I
understand that rvalue used to represent a value of something and
lvalue used to represent a piece of storage where the value could be
stored. But this no longer holds and you could find many
counterexamples to this description. Better description of rvalue
would be that it is either a temporary or a literal. One of the aims
of rvalue references is to filter temporaries from non-temporaries.
Regards,
&rzej
--
Greg Herlihy
> answer to the question "What's an lvalue/rvalue?"
> So is there any short enough description this groupd can come
> up with?
An "lvalue" is a value that resides in program memory (so an lvalue is
an "addressable" value). The value of an "rvalue" is one that -
conceptually at least - does not require storage in program memory.
(So, unlike the value of an lvalue, the value of an rvalue is usually
not accessible indirectly, say, via a pointer or a reference).
In practical terms, an rvalue often represents a value that is loaded
directly into a machine register or a value that is incorporated into
a particular machine instruction (such as an "immediate" value in an
"add immediate" assembly language instruction).
Greg
--
Alberto Ganesh Barbati
> Hi,
>
> as a second job I am teaching C++. I have only 3-4 months to
> teach it to students who had two semesters of exposure to
> Java.
> What I have learned doing this is that I need to find concise
> definitions for everything I want them to remember. Sometimes
> such definitions are surprisingly hard to find.
> One of the problems I keep running into is finding a good
> answer to the question "What's an lvalue/rvalue?" I have asked
> for a concise definition for this in newsgroups several times
> and searched the archives for other discussions of the topic,
> so I know impossible to come up with an easy definition. Yet I
> really do need to come up with a definition myself that needs
> to be simple enough to be remembered by my students while still
> being correct. (This will become even more urgent once rvalue
> references will become available.)
> So is there any short enough description this groupd can come
> up with?
You couldn't find a concise definition, because lvalues and rvalues are
not defined abstractly in terms of one or more properties they may
possess, but they are defined constructively in terms of how you can
obtain them.
An rvalue is:
- the value yielded by certain built-in operators (for example +, -, /,
etc.), or
- the result of calling a function that does not return a reference, or
- an expression which holds a temporary object resulting from a cast to
a nonreference type.
Every expression which is not an rvalue is an lvalue.
You may find this "definitions" unsatisfactory, however they are, to my
knowledge, the most accurate.
There was a legacy definition of lvalue which come from the C language
that says "an lvalue is an expression that you could put on the left
side of an assigment". The "l" in lvalue in fact stands for "left". For
contrast, when the concept of non-lvalue was subsequently introduced, it
was natural to use the term rvalue with the "r" standing for "right".
However, this definition is no longer acceptable in C++ (nor in C)
because of the introduction of the const qualifier: you can have const
lvalues which are lvalues but can't be used as assignment targets.
HTH,
Ganesh
--
Bart van Ingen Schenau
> Hi,
>
> as a second job I am teaching C++. I have only 3-4 months to
> teach it to students who had two semesters of exposure to
> Java.
> What I have learned doing this is that I need to find concise
> definitions for everything I want them to remember. Sometimes
> such definitions are surprisingly hard to find.
> One of the problems I keep running into is finding a good
> answer to the question "What's an lvalue/rvalue?" I have asked
> for a concise definition for this in newsgroups several times
> and searched the archives for other discussions of the topic,
> so I know impossible to come up with an easy definition. Yet I
> really do need to come up with a definition myself that needs
> to be simple enough to be remembered by my students while still
> being correct. (This will become even more urgent once rvalue
> references will become available.)
> So is there any short enough description this groupd can come
> up with?
The most clear and concise description that I can come up with is:
- An lvalue is anything that has object type and where you can take its
address.
- An rvalue are all non-lvalue entities with object type.
So, the basic distinction is if it has an address that you can obtain
within a program.
The only niggling doubt that I have is that the newly introduced rvalue
references run afoul of this description.
>
> TIA,
>
> Schobi
>
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
Nagrik
wrote:
>
> - Show quoted text -
Schober,
You can think of lvalue as "Location value" and thus you could not say
5 = a, because 5 does not have a location. And in the same breath you
can say rvalue as the read value,
lvalues are always a subset or rvalues.
I hope it helps to students.
nagrik
--
Alberto Ganesh Barbati
>
> lvalues are always a subset or rvalues.
>
That is incorrect. lvalue and rvalues are mutual exclusive concepts (see
§3.10/1).
Ganesh
Phil Hobbs
on the left side of an assignment, and an rvalue was anything that could
appear on the right--left-value and right-value, in other words.
I gather that this isn't true in detail anymore, hence the tortured
acronym expansions...
What are the exceptions to the left-value and right-value definitions?
Cheers,
Phil Hobbs
Francis Glassborow
exactly what an lvalue and an rvalue is.
Consider:
int a(0);
int b(1);
Are a and b lvalues or rvalues? The answer is unambiguous they are
lvalues. Note they are NOT rvalues, however in context the convert to
rvalues:
a = b;
Now b is converted to an rvalue before being used to assign to b.
Any object is either an rvalue or an lvalue, never both simultaneously
however an lvalue can be converted to an rvalue (by 'extracting the
value read)
None of this would matter were it not for C++s complex rules regarding
what can be done with each. Note that rvalues unlike C's values are not
necessarily immutable.
Alf P. Steinbach
>
> as a second job I am teaching C++. I have only 3-4 months to
> teach it to students who had two semesters of exposure to
> Java.
> What I have learned doing this is that I need to find concise
> definitions for everything I want them to remember. Sometimes
> such definitions are surprisingly hard to find.
> One of the problems I keep running into is finding a good
> answer to the question "What's an lvalue/rvalue?" I have asked
> for a concise definition for this in newsgroups several times
> and searched the archives for other discussions of the topic,
> so I know impossible to come up with an easy definition. Yet I
> really do need to come up with a definition myself that needs
> to be simple enough to be remembered by my students while still
> being correct. (This will become even more urgent once rvalue
> references will become available.)
> So is there any short enough description this groupd can come
> up with?
Uhm, I don't find any of the answers so far entirely satisfactory, and some
are
incorrect.
The simplest explanation I know is that an rvalue, in current C++, is an
/expression/ that produces a value, e.g. 42, and an lvalue is an expression
that
just refers to some existing object or function[1]. Hence the acronym
"locator
value"[2], which however is still misleading because an lvalue is simply not
a
value. Better would be rexpression versus lexpression, and even better,
just
value versus reference (unfortunately the term "reference" is already
hijacked).
"object" versus "value": in C++ the basic definition of "object" is a region
of
storage, i.e. anything that actually occupies storage, while a pure value
such
as 42 doesn't necessarily occupy any storage. A value (an rvalue) can be an
object, though. If it is, then it's a temporary object.
C++ allows you to call member functions on a class type rvalue, i.e. on a
temporary class type object.
The ability to call member functions on (class type) rvalues, together with
C++'s treatment of assignment operator as a member function (automatically
generated if needed and none defined), means that you can assign to class
type
rvalues. However, C++ does not regard that rvalue to be /modifiable/: to be
well-defined, the assignment must do something else than modifiying the
object
assigned to (and typically we indicate that by declaring the assignment
operator
const). §3.10/14 "A program that attempts to modify an object through a
nonmodifyable lvalue or rvalue expression is ill-formed".
Fine point: §3.10/14 means that rvalue-ness transfers to parts of an rvalue,
which are thereby also considered rvalues. However, at least the two
compilers I
use don't seem to know that rule. Comeau Online does.
I'm not sure if the explanation above holds up with respect to C++0x rvalue
references. rvalue versus lvalue got a lot more complicated in C++ than in
original C. Perhaps it's even more complicated in C++0x, I don't know. :-)
Cheers, & hth.,
- Alf
Notes:
[1] Amazingly that's also the general definition the standard starts out
with,
before going into details: §3.10/2 "An lvalue refers to an object or
function",
however, it would have helped much if the word "expression" was explicitly
included there, not just by being mentioned in the preceding paragraph.
[2] Unfortunately the C++ standard doesn't use or even mention the acronym
"locator value". This acronym comes from the current C standard. And
ironically
the C++ standard mentions, by contextual placement, the original old C
acronym
of "left hand value", in §3.10/4: "built-in assignment operators all expect
their left hand operands to be lvalues".
--
Ron Natalie
> I'm not sure if the explanation above holds up with respect to C++0x
> rvalue references. rvalue versus lvalue got a lot more complicated in
> C++ than in original C. Perhaps it's even more complicated in C++0x, I
> don't know. :-)
>
It's way more complicated in C++ than C because C doesn't even define
rvalue. It just has things that are lvalues and things that are not
lvalues.
Hendrik Schober
> [...]
I apologize for not being able to get back sooner. Thank you to
everybody who answered.
I'll try to recap the answers:
Martin York <Martin.Y...@gmail.com> wrote:
> [...]
> Simple (but not too simplistic) and easy to remember
> =====================================================
> lvalue: an expression that can be placed on the left hand side of an
> assignment.
> rvalue: an expression that can be placed on the right hand side of an
> assignment.
For C++, this isn't really correct anymore (const lvalues
have been mentioned, I think). Also, even if it was true,
the problem was that I need the students to learn what can
be put on the lhs side of an assignment operator.
Alberto Ganesh Barbati <Alberto...@libero.it> wrote:
> [...]
> You couldn't find a concise definition, because lvalues and rvalues are
> not defined abstractly in terms of one or more properties they may
> possess, but they are defined constructively in terms of how you can
> obtain them.
>
> An rvalue is:
>
> - the value yielded by certain built-in operators (for example +, -, /,
> etc.), or
>
> - the result of calling a function that does not return a reference, or
>
> - an expression which holds a temporary object resulting from a cast to
> a nonreference type.
> [...]
Is this really the whole list? If that's all, it's easy
enough to remember. (To me this list looks like rvalues
are a synonym to what's usually referred to as "temporary
object". Is that right?)
Alf P. Steinbach <al...@start.no> wrote:
> [...]
> Uhm, I don't find any of the answers so far entirely satisfactory, and some
> are incorrect.
I suppose these have all been corrected by now?
> The simplest explanation I know is that an rvalue, in current C++, is an
> /expression/ that produces a value, e.g. 42, and an lvalue is an expression
> that just refers to some existing object or function[1]. [...]
> "object" versus "value": in C++ the basic definition of "object" is a region
> of storage, i.e. anything that actually occupies storage, while a pure value
> such as 42 doesn't necessarily occupy any storage. [...]
Some others have posted something similar, however,
I'm not sure that students will be able to tell which
expression yields something that has an address and
which doesn't.
Schobi
--
Spam...@gmx.de is never read
I'm HSchober at gmx dot de
"I guess at some point idealism meets human nature and
explodes." Daniel Orner
Alf P. Steinbach
> Hendrik Schober <Spam...@gmx.de> wrote:
>> [...]
>
> I apologize for not being able to get back sooner. Thank you to
> everybody who answered.
> I'll try to recap the answers:
>
>
>
> Martin York <Martin.Y...@gmail.com> wrote:
>> [...]
>> Simple (but not too simplistic) and easy to remember
>> =====================================================
>> lvalue: an expression that can be placed on the left hand side of an
>> assignment.
>> rvalue: an expression that can be placed on the right hand side of an
>> assignment.
>
> For C++, this isn't really correct anymore (const lvalues
> have been mentioned, I think).
Also, most rvalue expressions of class type can be placed on the left hand side
of an assignment, because that assignment is a call of operator= member
function, and you can call member functions on rvalues.
This leads to an absurd situation where you can assign to the complete result of
a function call, because it's of class type and so with operator= so that the
assignment is a member function call, but not to a part of the function's
result, doing the equivalent of the full assignment in smaller bites, because
that you can't use built-in assignment on rvalues.
<code>
struct S{ int x; S():x(){} };
S foo() { return S(); }
int main()
{
foo() = S();
foo().x = 0; // Not allowed, but accepted by g++ 3.4.4
}
</code>
> Also, even if it was true,
> the problem was that I need the students to learn what can
> be put on the lhs side of an assignment operator.
For built-in types, only non-const lvalue expressions, such as name of variable.
For class types, any expression where the relevant assignment operator is
accessible and compatible wrt. constness and volatile (cv-qualification).
> Alberto Ganesh Barbati <Alberto...@libero.it> wrote:
>> [...]
>> You couldn't find a concise definition, because lvalues and rvalues are
>> not defined abstractly in terms of one or more properties they may
>> possess, but they are defined constructively in terms of how you can
>> obtain them.
>>
>> An rvalue is:
>>
>> - the value yielded by certain built-in operators (for example +, -, /,
>> etc.), or
>>
>> - the result of calling a function that does not return a reference, or
>>
>> - an expression which holds a temporary object resulting from a cast to
>> a nonreference type.
>
>> [...]
>
> Is this really the whole list? If that's all, it's easy
> enough to remember. (To me this list looks like rvalues
> are a synonym to what's usually referred to as "temporary
> object". Is that right?)
It looks fairly complete.
But keep in mind that rvalues and lvalues are not values. They're expressions,
that designate respectively values and references.
> Alf P. Steinbach <al...@start.no> wrote:
>> [...]
>> Uhm, I don't find any of the answers so far entirely satisfactory, and some
>> are incorrect.
>
> I suppose these have all been corrected by now?
Well, you corrected Martin York's explanation above, in one respect.
Greg Herlihy wrote "The value of an "rvalue" is one that - conceptually at least
- does not require storage in program memory", which is generally incorrect for
class type rvalues. But I suspect he didn't mean what he literally wrote. I
think he meant that an lvalue expression always designates something with an
address, whereas that is not the case for an rvalue expression.
Bart van Ingen Schenau wrote "An lvalue is anything that has object type and
where you can take its address", which is incorrect in two ways. First, an
lvalue need not be of object type, it can be of function type, and that's the
second sentence in the standard about lvalues. Second, for an rvalue of class
type where the class defines an address operator member (not a good idea, as
Microsoft belatedly realized for their MFC and ATL libraries, then introducing a
kind of wrapper class to allow those dirty classes to be used in containers!),
you may have an rvalue that you can take the address of. Bart just put the
implications the wrong way. If you have an lvalue expression, then it refers to
an object with an address, but if you can take the address of the object an
expression refers to then the expression need not be an lvalue, because it might
refer to an object of class type with defined address operator.
(Also, Nagrik wrote "lvalues are always a subset of rvalues", but that has
already been corrected.)
>> The simplest explanation I know is that an rvalue, in current C++, is an
>> /expression/ that produces a value, e.g. 42, and an lvalue is an expression
>> that just refers to some existing object or function[1]. [...]
>> "object" versus "value": in C++ the basic definition of "object" is a region
>> of storage, i.e. anything that actually occupies storage, while a pure value
>> such as 42 doesn't necessarily occupy any storage. [...]
>
> Some others have posted something similar, however,
> I'm not sure that students will be able to tell which
> expression yields something that has an address and
> which doesn't.
Think of rvalues as expressions that yield values, and lvalues as expressions
that yield references.
The only really complicating factor is that you can call member functions on
values of class type, which, as illustrated above, includes assignment!
And in C++0x, a further complication is that much of the point of rvalue
references is to suck out the innards of a class type rvalue (temporary) and
place it somewhere else, which involves /modifying/ a value... :-)
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Seungbeom Kim
> * Hendrik Schober:
>> Also, even if it was true,
>> the problem was that I need the students to learn what can
>> be put on the lhs side of an assignment operator.
>
> For built-in types, only non-const lvalue expressions, such as name of
> variable.
Things that are lvalues but not qualified on the left-hand side (or as
the operand of ++ or --) are called "nonmodifiable lvalues". A const-
qualified expression is certainly nonmodifiable; another example is an
array name.
int a[10], b[10];
a = b; // ill-formed
a++; // ill-formed
--
Seungbeom Kim
Alberto Ganesh Barbati
>
> Alberto Ganesh Barbati <Alberto...@libero.it> wrote:
>> [...]
>> You couldn't find a concise definition, because lvalues and rvalues are
>> not defined abstractly in terms of one or more properties they may
>> possess, but they are defined constructively in terms of how you can
>> obtain them.
>>
>> An rvalue is:
>>
>> - the value yielded by certain built-in operators (for example +, -, /,
>> etc.), or
>>
>> - the result of calling a function that does not return a reference, or
>>
>> - an expression which holds a temporary object resulting from a cast to
>> a nonreference type.
>
>> [...]
>
> Is this really the whole list? If that's all, it's easy
> enough to remember.
Broadly speaking, that's all. The list is taken straight from 3.10 of
the C++ standard. However, what is missing is to know which of every
single built-in operator yield rvalues and for that you need to refer to
clause 5. I guess it should not be too difficult to create a summarizing
table about that.
Please notice that the second bullet is going to change in C++0x to:
"the result of calling a function that does not return *an lvalue*
reference" (emphasis added).
> (To me this list looks like rvalues
> are a synonym to what's usually referred to as "temporary
> object". Is that right?)
The two concepts are tightly related but they are not synonyms. As
correctly remarked by Alf P. Steinback, the key point is that rvalues
and lvalues are *expressions*, not objects. Let me put it this way:
during the evaluation of an expression, the compiler *may* need to hold
intermediate results of some sub-expressions. Lvalue sub-expressions
always refer to objects that are already stored somewhere, the lifetime
of these objects is managed outside the evaluation of the full
expression. Oppositely, rvalue sub-expressions may require the creation
of new "temporary" objects to hold their values, the lifetime of such
objects is managed as part of the evaluation of the full expression.
Noticed that I stressed "may" above. An rvalue expression of a built-in
type may be stored in a CPU register so, technically speaking, it does
not give birth to a temporary object (see 1.8/1: "an object is a region
of storage" where "storage" implies addressability by 1.7/1, so a CPU
register does not qualify). Another case is this:
A a;
A b(static_cast<A&&>(a));
although static_cast<A&&>(a) is an rvalue expression, no temporary
object is created.
HTH,
Ganesh
--
Alf P. Steinbach
>
> The ability to call member functions on (class type) rvalues, together
> with C++'s treatment of assignment operator as a member function
> (automatically generated if needed and none defined), means that you can
> assign to class
> type rvalues. However, C++ does not regard that rvalue to be
> /modifiable/: to be well-defined, the assignment must do something else
> than modifiying the
> object assigned to (and typically we indicate that by declaring the
> assignment
> operator const). §3.10/14 "A program that attempts to modify an object
> through a nonmodifyable lvalue or rvalue expression is ill-formed".
Huh. I'm sorry, but the above isn't meaningful to me, now when I read it. Not
sure what I was thinking, or whether I was thinking, but possibly confused by
§3.10/14.
§3.10/14 does in fact not state what I described above, unless it's parsed as
"through a (nonmodifyable lvalue) or (rvalue) expression", but in that case it
would contradict §10/10 that says that some rvalues can be modified.
The above quoted second sentence of §3.10/14 seems to say absolutely nothing: it
apparently just 100% circularly notes that an expression that can't be used to
modify objects, can't be used to modify objects. It doesn't add a requirement
of a diagnostic on violation of that rule, because the default §1.4/1 is that
any rule broken by the code requires a diagnostic, so if the code modifies an
object through a nonmodifiable expression, defined by the first §3.10/14
sentence as an expression that "can [not] be used to modify the object to which
it refers", then the code breaks whatever rule that says that the expression can
not be used to modify the object, and so a diagnostic is already required. I
think it was this apparent total lack of meaning of the second sentence of
§3.10/14 that caused me to see or imagine a meaning that just isn't there.
> Fine point: §3.10/14 means that rvalue-ness transfers to parts of an
> rvalue,
> which are thereby also considered rvalues. However, at least the two
> compilers I use don't seem to know that rule. Comeau Online does.
And this follow-up conclusion goes down the drain, too.
I'm now wondering what rule of the standard the Comeau compiler relies on?
Sorry for the confusion, & hoping some language lawyer can clear this up,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Hendrik Schober
>>> [...]
>>> You couldn't find a concise definition, because lvalues and rvalues are
>>> not defined abstractly in terms of one or more properties they may
>>> possess, but they are defined constructively in terms of how you can
>>> obtain them.
>>>
>>> An rvalue is:
>>>
>>> - the value yielded by certain built-in operators (for example +, -, /,
>>> etc.), or
>>>
>>> - the result of calling a function that does not return a reference, or
>>>
>>> - an expression which holds a temporary object resulting from a cast to
>>> a nonreference type.
>>
>>> [...]
>>
>> Is this really the whole list? If that's all, it's easy
>> enough to remember. (To me this list looks like rvalues
>> are a synonym to what's usually referred to as "temporary
>> object". Is that right?)
>
> It looks fairly complete.
Thanks to both you and Ganesh to confirm (and elaborate).
> But keep in mind that rvalues and lvalues are not values. [...]
<head -> desk>
> [...]
> The only really complicating factor is that you can call member functions on
> values of class type, which, as illustrated above, includes assignment!
I knew that, although I don't think I ever noticed that it
would include assignment.
> And in C++0x, a further complication is that much of the point of rvalue
> references is to suck out the innards of a class type rvalue (temporary) and
> place it somewhere else, which involves /modifying/ a value... :-)
(The thought of having to teach rvalue references was what
brought me here to find a concise definition of revalues.)
> - Alf
Schobi
--
Spam...@gmx.de is never read
I'm HSchober at gmx dot de
"I guess at some point idealism meets human nature and
explodes." Daniel Orner
[ See http://www.gotw.ca/resources/clcm.htm for info about ]