lvalue/rvalue?

[Yarco]

I've alway thought lvalue means Left Value and rvalue means Right
Value before i've read someone's article.
It is said "lvalue = location value" and "rvalue = read value".
Which one is right, then?

 

[Guest]

I've alway thought lvalue means Left Value and rvalue means Right
Value before i've read someone's article.
It is said "lvalue = location value" and "rvalue = read value".
Which one is right, then?

I don't think it's ever specified in the standard what l and r stands
for, but it's probably left and right and definitely not location and read.

 

[Alf P. Steinbach]

* Yarco:

I've alway thought lvalue means Left Value and rvalue means Right
Value before i've read someone's article.
It is said "lvalue = location value" and "rvalue = read value".
Which one is right, then?

Originally, in C, lvalue and rvalue referred to "left" and "right" of
assignment. With the introduction of "const" and references in C++ you
have lvalues that cannot serve as the left hand side of assignment, and
also, you have rvalues that can be modified. So the author's acronym
expansions are better in the sense that they're not as misrepresenting.

 

[Kai-Uwe Bux]

I've alway thought lvalue means Left Value and rvalue means Right
Value before i've read someone's article.
It is said "lvalue = location value" and "rvalue = read value".
Which one is right, then?

The standard uses the words "lvalue" and "rvalue". It does not treat these
terms as abbreviations for anything but assigns meanings to them directly.
In particular, I do not find any of "location value", "left value", "read
value", or "right value" in the standard.

As far as I can see, "lvalue" just means lvalue and "rvalue" means rvalue.


Best

Kai-Uwe Bux

 

[Alf P. Steinbach]

* Kai-Uwe Bux:

As far as I can see, "lvalue" just means lvalue and "rvalue" means rvalue.

As I mentioned else-thread, these terms come originally from C.

Kernighan & Ritchie explained it thusly in "The C Programming Language"
(first edition, 1978): "The name "lvalue" comes from the assignment
expression E1 = E2 in which the left operand E1 must be an lvalue
expression" (of course that's no longer true in C++).

This exact wording is repeated in the C standard, to which the C++
standard refers and defers, with the added note: "It is perhaps better
considered as representing an object "locator value"".

 

[Kai-Uwe Bux]

* Kai-Uwe Bux:

As I mentioned else-thread, these terms come originally from C.

Kernighan & Ritchie explained it thusly in "The C Programming Language"
(first edition, 1978): "The name "lvalue" comes from the assignment
expression E1 = E2 in which the left operand E1 must be an lvalue
expression" (of course that's no longer true in C++).

That is an interesting etymological piece of information. It does, however,
not affect the meanings of the terms "lvalue" and "ravlue" as used in the
C++ standard.

This exact wording is repeated in the C standard, to which the C++
standard refers and defers, with the added note: "It is perhaps better
considered as representing an object "locator value"".

The general reference of the C standard in the C++ standard does not imply
that all definitions of terms of the C standard are incorporated and used
within the C++ standard. In particular, if the C++ standard defines terms
that also are defined in the C standard, the definitions from the C++
standard take precedence and the terms acquire a (possibly new) meaning in
the context of the C++ standard.

I do not see that the C++ refers and defers to the C standard with respect
to the meanings (or readings) of "lvalue" and "rvalue". Those terms are
defined by the C++ standard itself and, therefore, may or may not have a
different meaning than the notions of the C standard that happen to be
spelled identically.


Personally, I don't think that either reading ("locator value" or "left
value") is particularly good. I prefer to say, write, and _think_ "lvalue"
just as a memo to myself that it is a purely technical term whose meaning
is fully determined by rules given in the standard. Any association to
either locations or left sides of expressions runs the risk of being
misleading in certain contexts.


Best

Kai-Uwe Bux

 

[Alf P. Steinbach]

* Kai-Uwe Bux:

That is an interesting etymological piece of information. It does, however,
not affect the meanings of the terms "lvalue" and "ravlue" as used in the
C++ standard.

Right, and it doesn't affect the meanings in C either.

The general reference of the C standard in the C++ standard does not imply
that all definitions of terms of the C standard are incorporated and used
within the C++ standard. In particular, if the C++ standard defines terms
that also are defined in the C standard, the definitions from the C++
standard take precedence and the terms acquire a (possibly new) meaning in
the context of the C++ standard.

I do not see that the C++ refers and defers to the C standard with respect
to the meanings (or readings) of "lvalue" and "rvalue".

Bullshit.

Those terms are
defined by the C++ standard itself and, therefore, may or may not have a
different meaning than the notions of the C standard that happen to be
spelled identically.
Right.


Personally, I don't think that either reading ("locator value" or "left
value") is particularly good. I prefer to say, write, and _think_ "lvalue"
just as a memo to myself that it is a purely technical term whose meaning
is fully determined by rules given in the standard. Any association to
either locations or left sides of expressions runs the risk of being
misleading in certain contexts.

Yeah.

Cheers,

- Alf

 

[Kai-Uwe Bux]

* Kai-Uwe Bux:

Right, and it doesn't affect the meanings in C either.

Good to know.

Bullshit.

Could you please provide me with a reference? I just re-read [3.10], and I
did not find ISO/IEC 9899:1999 mentioned therein.

Yeah.

I feel that we are rapidly converging toward total agreement


Best

Kai-Uwe Bux

 

[James Kanze]

That is an interesting etymological piece of information. It does, however,
not affect the meanings of the terms "lvalue" and "ravlue" as used in the
C++ standard.

Certainly. It does, however, affect the rationale behind and
the motivation for that meaning. Knowing the history helps
understand the present.

The general reference of the C standard in the C++ standard does not imply
that all definitions of terms of the C standard are incorporated and used
within the C++ standard. In particular, if the C++ standard defines terms
that also are defined in the C standard, the definitions from the C++
standard take precedence and the terms acquire a (possibly new) meaning in
the context of the C++ standard.

And when the C++ standard doesn't re-define a term, but the C
standard does, the meaning in the C standard holds. And when
the C++ isn't clear, understanding the C standard can often help
understand intent---there are places (lvalue and rvalue are one)
where the C++ standard doesn't intentionally (and intentionally
doesn't) differ from the C standard.

In this case, of course, Alf said that it was a note. A
non-normative part of the standard, and not part of the official
"definition". Again, it helps in understanding the intent and
the motivation of lvalue. (It doesn't define it in a normative
sense.)

I do not see that the C++ refers and defers to the C standard with respect
to the meanings (or readings) of "lvalue" and "rvalue". Those terms are
defined by the C++ standard itself and, therefore, may or may not have a
different meaning than the notions of the C standard that happen to be
spelled identically.

Personally, I don't think that either reading ("locator value" or "left
value") is particularly good. I prefer to say, write, and _think_ "lvalue"
just as a memo to myself that it is a purely technical term whose meaning
is fully determined by rules given in the standard. Any association to
either locations or left sides of expressions runs the risk of being
misleading in certain contexts.

If you're arguing about an exact detail in the code, e.g.
whether something is legal or not, the only definition is that
derived from the specifications in section 5, in which it is
specified which expressions result in lvalues, when. If you're
trying to get a general feel for the "meaning" of the term, why
the standard even makes a distinction, etc., then the text that
Alf cited is very useful background information.

 

[Kai-Uwe Bux]

On Jul 15, 7:25 pm, Kai-Uwe Bux <[email protected]> wrote:

[snipped stuff where we don't disagree]

And when the C++ standard doesn't re-define a term, but the C
standard does, the meaning in the C standard holds.

That sounds interesting and seems quite general a claim. I was not aware
that the C++ standard makes such strong reference to the C standard. I only
noticed that ISO/IEC 2382 is incorporated this way in [1.3]. The only
similar move with regard to C that I was aware of is the claim that the C++
standard library contains the C standard library as a subset (with some
explicitly mentioned exceptions and qualifications).

Could you point me to the clause where the C++ standard indiscriminately
incorporates all definitions from the C standard as default meanings?

And when
the C++ isn't clear, understanding the C standard can often help
understand intent---
Certainly!

there are places (lvalue and rvalue are one)
where the C++ standard doesn't intentionally (and intentionally
doesn't) differ from the C standard.

Just a nit: I am not so sure that I would say the meanings or definitions
of "lvalue" in the C and the C++ standard "do not differ". I would probably
choose a slightly different wording and say that the C++ standard extends
or re-defins the term in a _conservative way_. If pressed to explain what a
conservative extension is, I would say that for programs in the common
subset of C an C++, whether an expression is an lvalue does not depend on
whether the program is read as a C or as a C++ program.

Of course, there are good systematic and obvious historical reasons why the
C++ standard often chooses the conservative way with regard to terms
already used to define C.

[snipped other stuff where we don't disagree]


Best

Kai-Uwe Bux