r- r-value vs l-value?

[Zach]

Can someone please explain what this means and illustrate the
difference with some code.

Thanks,
Zach

[Chris Smith]

Zach <ne****@gmail.c om> wrote:

Can someone please explain what this means and illustrate the
difference with some code.

Sure. An l-value is an expression that may legally appear on the left-
hand side of the assignment operator, =. An r-value is an expression
that may appear on the right-hand side. The set of r-values is a subset
of the the set of l-values. For example, given:

int a;
int b[50];

The following are l-values (and also r-values):

a
b[10]

Whereas the following are ONLY r-values:

17
a + 5
b

Therefore, the following line of code will fail to compile:

a + 5 = 15;

Hope that helps,

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

[Richard Heathfield]

Chris Smith said:

Zach <ne****@gmail.c om> wrote:

Can someone please explain what this means and illustrate the
difference with some code.
Sure. An l-value is an expression that may legally appear on the left-
hand side of the assignment operator, =.

More formally, "an lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not designate an object
when it is evaluated, the behaviour is undefined."

An r-value is an expression that may appear on the right-hand side. The set of r-values is a subset
of the the set of l-values. For example, given:

int a;
int b[50];

The following are l-values (and also r-values):

a
b[10]

Whereas the following are ONLY r-values:

17
a + 5
b

Strictly speaking, b is an lvalue, but not a modifiable lvalue. Section
6.3.2.1(1) - which I quoted above - goes on to say: "A modifiable lvalue is
an lvalue that does not have array type, does not have an incomplete type,
does not have a const-qualified type, and if it is a structure or union,
does not have any member (including, recursively, any member or element of
all contained aggregates or unions) with a const-qualified type."

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chris Smith]

Richard Heathfield <in*****@invali d.invalid> wrote:

Strictly speaking, b is an lvalue, but not a modifiable lvalue. Section
6.3.2.1(1) - which I quoted above - goes on to say: "A modifiable lvalue is
an lvalue that does not have array type, does not have an incomplete type,
does not have a const-qualified type, and if it is a structure or union,
does not have any member (including, recursively, any member or element of
all contained aggregates or unions) with a const-qualified type."

Interesting... is there a situation in legal code where this makes a
difference?

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

[Zach]

Chris Smith wrote:

Sure. An l-value is an expression that may legally appear on the left-
hand side of the assignment operator, =. An r-value is an expression
that may appear on the right-hand side. The set of r-values is a subset
of the the set of l-values. For example, given:

int a;
int b[50];

The following are l-values (and also r-values):

a
b[10]

Whereas the following are ONLY r-values:

17
a + 5
b

Therefore, the following line of code will fail to compile:

a + 5 = 15;

Hope that helps,

Where are the rules of what may go on each side?

Zach

[pete]

Chris Smith wrote:

Richard Heathfield <in*****@invali d.invalid> wrote:

Strictly speaking, b is an lvalue,
but not a modifiable lvalue. Section
6.3.2.1(1) - which I quoted above - goes on to say:
"A modifiable lvalue is
an lvalue that does not have array type,
does not have an incomplete type,
does not have a const-qualified type,
and if it is a structure or union,
does not have any member (including, recursively,
any member or element of
all contained aggregates or unions) with a const-qualified type."

Interesting... is there a situation in legal code where this makes a
difference?

If (b) was not an lvalue,
then (&b) would be undefined.

--
pete

[Walter Roberson]

In article <44***********@ mindspring.com> ,
pete <pf*****@mindsp ring.com> wrote:

Chris Smith wrote:

Richard Heathfield <in*****@invali d.invalid> wrote:

> Strictly speaking, b is an lvalue,
> but not a modifiable lvalue.

Interesting... is there a situation in legal code where this makes a
difference?

If (b) was not an lvalue,
then (&b) would be undefined.

I believe Richard and Chris are talking about lvalue as compared
to "modifiable lvalue".
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

[Keith Thompson]

Richard Heathfield <in*****@invali d.invalid> writes:

Chris Smith said:

Zach <ne****@gmail.c om> wrote:

Can someone please explain what this means and illustrate the
difference with some code.

Sure. An l-value is an expression that may legally appear on the left-
hand side of the assignment operator, =.

More formally, "an lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not designate an object
when it is evaluated, the behaviour is undefined."

[...]

Which, as I've argued before, is a poor definition.

The C90 standard's definition is:

An _lvalue_ is an expression (with an object type or an incomplete
type other than void) that designates an object.

The problem with this is that, if it's interpreted literally, certain
expressions are or are not lvalues depending on their current values.
For exmaple if p is a pointer to int that currently points to an int
object, then *p is clearly an lvalue -- but if p == NULL, then *p
doesn't currently designate an object. Since lvalueness determines
compile-time legality, this clearly wasn't the intent.

The C99 standard's definition, which Richard quoted above, was
intended to correct this problem -- and it did, but at the expense of
introducing another one. Designating an object is what lvalueness is
all about; the C99 definition lost this. For example, 42 is "an
expression with an object type ...", so, if the definition is to be
taken literally, 42 is an lvalue. And since it doesn't designate an
object, evaluating 42 invokes undefined behavior. Again, this clearly
isn't what was intended.

What the definition *should* say is that an lvalue is an expression
with an object type or an incomplete type other than void that
designates or *potentially* designates an object. For example, *p
potentially designates an object, depending on the current value of p,
but *p is an lvalue regardless of the value of p. C99's statement
that "if an lvalue does not designate an object when it is evaluated,
the behaviour is undefined" is then valid. The problem is defining
the phrase "potentiall y designates" (or some equivalent phrase) in
standardese.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Erik Wikström]

On 2006-06-05 03:55, Zach wrote:

Chris Smith wrote:

Sure. An l-value is an expression that may legally appear on the left-
hand side of the assignment operator, =. An r-value is an expression
that may appear on the right-hand side. The set of r-values is a subset
of the the set of l-values. For example, given:

int a;
int b[50];

The following are l-values (and also r-values):

a
b[10]

Whereas the following are ONLY r-values:

17
a + 5
b

Therefore, the following line of code will fail to compile:

a + 5 = 15;

Hope that helps,

Where are the rules of what may go on each side?

A nice rule is "when it makes sense". An l-value is something you can
(after evaluation) assign a value to and an r-value is a value (again,
after evaluation) that can be assigned. Generally speaking this means
that an l-value evaluates to a variable (or and index into an array)
while an r-value evaluates to a value of the same type as the l-value.

Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

[onkar]

L-value -> something u can store to -> mem location
R-value -> something u can read from -> variable
you cant store to (a+5) , if a is int
but you can store to *(a+5), where a is int*

Onkar
Erik Wikström wrote:

On 2006-06-05 03:55, Zach wrote:

Chris Smith wrote:

Sure. An l-value is an expression that may legally appear on the left-
hand side of the assignment operator, =. An r-value is an expression
that may appear on the right-hand side. The set of r-values is a subset
of the the set of l-values. For example, given:

int a;
int b[50];

The following are l-values (and also r-values):

a
b[10]

Whereas the following are ONLY r-values:

17
a + 5
b

Therefore, the following line of code will fail to compile:

a + 5 = 15;

Hope that helps,

Where are the rules of what may go on each side?

A nice rule is "when it makes sense". An l-value is something you can
(after evaluation) assign a value to and an r-value is a value (again,
after evaluation) that can be assigned. Generally speaking this means
that an l-value evaluates to a variable (or and index into an array)
while an r-value evaluates to a value of the same type as the l-value.

Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup