Lvalue?

[the_init]

Hi friends,

I read about Lvalue in previous posting and Googled it but I'm not
understood it completely.
There is a small doubt.

int a;
a=20; // here a is Lvalue

But

What is the Lvalue in the following example.

struct Node
{
int a;
int b;
};

struct Node tempNode1, tempNode2;

tempNode1.a=2;
tempNode1.b=3;

tempNode2=tempNode1; // What is the Lvalue in this case.


Thanks...

 

[Frederick Gotham]

the_init:

int a;
a=20; // here a is Lvalue

Correct.

But

What is the Lvalue in the following example.

struct Node
{
int a;
int b;
};

struct Node tempNode1, tempNode2;

tempNode1.a=2;
tempNode1.b=3;

tempNode2=tempNode1;

All of them are L-values. The rule of thumb is: "If it can appear on the
left-hand side of an assignment statement, then it is an L-value".

The L-values we're most familiar with are simple objects:

int a; a = 5;
double k; k = 4;

, but we can also obtain L-values from other places, e.g.:

*p = 5;

 

[Keith Thompson]

I read about Lvalue in previous posting and Googled it but I'm not
understood it completely.
There is a small doubt.

int a;
a=20; // here a is Lvalue

But

What is the Lvalue in the following example.

What do you mean by *the* lvalue? There isn't necessarily a single
lvalue in an expression or statement; there could be multiple lvalues,
or there could be multiple lvalues.

struct Node
{
int a;
int b;
};

struct Node tempNode1, tempNode2;

tempNode1.a=2;
tempNode1.b=3;

tempNode2=tempNode1; // What is the Lvalue in this case.

An lvalue is an expression that (potentially) designates an object.
Some expression contexts require an lvalue; others do not. The left
hand side of an assignment expression requires an lvalue (that's where
the name "lvalue" comes from; the 'l' stands for "left"). In the
assignment

tempNode2 = tempNode1;

both tempNode1 and tempNode2 happen to be lvalues, since they both
designate objects, but only tempNode2 is used in a context that
requires an lvalue.

 

[Andrey Tarasevich]

...
All of them are L-values. The rule of thumb is: "If it can appear on the
left-hand side of an assignment statement, then it is an L-value".
...

No, actually. The rule of the thumb is: "If you can apply the unary '&' to it,
then it is an Lvalue". This also isn't absolutely accurate (especially if
treated as "then and only then" rule), but much closer to the truth that the
"assignment-based" version.

 

[Richard Heathfield]

Andrey Tarasevich said:

No, actually. The rule of the thumb is: "If you can apply the unary '&' to
it, then it is an Lvalue". This also isn't absolutely accurate (especially
if treated as "then and only then" rule), but much closer to the truth
that the "assignment-based" version.

The "assignment-based" version is even more broken than you suggest, at
least as currently stated. In the statement:

foo[6] = 42;

6 appears on the left side of an assignment statement, and yet 6 is not an
lvalue.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

 

[pete]

Andrey Tarasevich wrote:

The rule of the thumb is: "If you can apply the unary '&' to it,
then it is an Lvalue".

This also isn't absolutely accurate (especially if
treated as "then and only then" rule),
but much closer to the truth that the
"assignment-based" version.

The two simplest exceptions are that
identifiers of functions can be operands of &,
but are not lvalues,
and identifiers of register class objects can't be operands of &,
but are lvalues.

 

[Keith Thompson]

Andrey Tarasevich said:

No, actually. The rule of the thumb is: "If you can apply the unary '&' to
it, then it is an Lvalue". This also isn't absolutely accurate (especially
if treated as "then and only then" rule), but much closer to the truth
that the "assignment-based" version.

The "assignment-based" version is even more broken than you suggest, at
least as currently stated. In the statement:

foo[6] = 42;

6 appears on the left side of an assignment statement, and yet 6 is not an
lvalue.

Of course, but that flaw is easily corrected by changing

If it can appear on the left-hand side of an assignment statement ...

to

If it can be the left operand of an assignment operator ...

It was a failure of wording, not of understanding. (Also, assignment
is an expression, not a statement.)

The "assignment-based" version is not *horribly* wrong; in fact, it's
the basis for the term "lvalue". I tend to use the idea as the basis
of a mnemonic ("lvalue" ... 'l' as in left, as in left-hand-side of an
assignment ... oh, yes, that's what it means) while keeping in mind
that it's not nearly that simple.

But if you want an actual definition of the term, an lvalue is just an
expression that (potentially) designates an object. (The word
"potentially" is necessary to allow for the fact that *ptr is an
lvalue even if ptr==NULL, something that both the 1990 and 1999 C
standards have screwed up.)

<OT>C++'s definition of "lvalue" differs from C's definition, but is
no more complicated. A recent length discussion of C++ was both
off-topic and needlessly obfuscated.</OT>

 

[Ben Bacarisse]

No, actually. The rule of the thumb is: "If you can apply the unary '&' to it,
then it is an Lvalue". This also isn't absolutely accurate (especially if
treated as "then and only then" rule), but much closer to the truth that the
"assignment-based" version.

I can't see why one rule of thumb is better than the other. Some
examples of what you had in mind would have helped. I tried to think
of how the two "rules" fail and came up with:

Expressions that are lvalues but

"can not be assigned to" "can not be the operand of unary &"
arrays bit-fields

Expressions that are not lvalues but

"can be assigned to" "can be the operand of unary &"
??? function names

What have I missed? Why is one rule "much closer" than the other?

 

[Ben Bacarisse]

I can't see why one rule of thumb is better than the other. Some
examples of what you had in mind would have helped. I tried to think
of how the two "rules" fail and came up with:

Expressions that are lvalues but

"can not be assigned to" "can not be the operand of unary &"
arrays bit-fields

I could have added string literals to this first columns since these
are lvalues that can not be assigned to, but modifying such an object
is "only" UB rather than a constraint volation!

 

[Andrey Tarasevich]

...


The two simplest exceptions are that
identifiers of functions can be operands of &,
but are not lvalues,

Well, a better version of the rule would probably be the one that deals with
"objects" specifically.

and identifiers of register class objects can't be operands of &,
but are lvalues.

As are bit-fields. That's the reason I said it is not entirely accurate. Yet I
still believe that the '&'-based version better conveys the idea of lvalue as
something that has a place in storage.

 

[Andrey Tarasevich]

...
I can't see why one rule of thumb is better than the other. Some
examples of what you had in mind would have helped. I tried to think
of how the two "rules" fail and came up with:

Expressions that are lvalues but

"can not be assigned to" "can not be the operand of unary &"
arrays bit-fields

Expressions that are not lvalues but

"can be assigned to" "can be the operand of unary &"
??? function names

What have I missed? Why is one rule "much closer" than the other?
...

One reason I don't like the assignment-based version is because it discards a
large "class" of lvalues - constant objects. To me this does not feel like a
small and fairly negligible exception, acceptable in a "rule of thumb".

The assignment-based version correctly describes only one particular kind of
lvalues - _modifiable_ ones, - while completely ignoring the existence of
non-modifiable lvalues (of which arrays are another example).