Temporaries

[Francesco]

I understand that a function call is not an lvalue

Forgot one word. I meant to write "...a function call isn't
_necessarily_ an lvalue", just like the clause you cited reads in
other - more precise - words.

Francesco

 

[Francesco]

I've been reading several topics on comp.std.c++, and I've come to
read some posts of yours, James, which illuminated me.

One passage in particular:
"In C, I could always imagine that if something had an address, it was
an
lvalue. But even there -- on some of the machines I've worked on,
there
were no floating point registers, nor floating point immediate
instructions, and floating point literals had an address. And of
course, in C++...

In the end, in this group (comp.STD.c++), an lvalue is something that
the standard says is an lvalue -- the definition is spread out all
over
chapter 5, and a few other places as well. Elsewhere, I think it is
almost one of those "I know it when I see it, but I can't explain it"
sort of things.

None of which, of course, is particularly intellectually satisfying."

That's interesting because I've had just the same thoughts by only
basing on Stroustrups' words about lvalues, but apart from that, your
words make me understand what was going wrong in my reasoning about
considering an lvalue everything that I could get the address of -
with ref. to literal doubles actually having an address on some
machines. I think I understand the whole thing a bit better now.

It's a shame that nobody replied to your post there, James. Basing on
my poor knowledge of the situation, your point was a very important
one.

Best regards,
Francesco.

 

[James Kanze]

[...]

I understand that a function call is not an lvalue, but I
never said so - but once again I understand that my words
could have been interpreted that way. I meant to say that the
result of that call is a temporary, and I consider the
_temporary_ to be an lvalue, and I consider it to be an lvalue
just because I can get its address. This can be arguable and
will likely be, and eventually I'll be proved wrong. No
problem.

First, very importantly, lvalue is part of the vocabulary of the
standard; it's part of a dialect of English sometimes known as
standardese. I'd say it was a "Humpty-Dumpty" language, but as
you're not a native English speaker, I'm not sure you'd get the
reference---in Lewis Carroll's _Through the Looking Glass_,
Alice has a discussion with Humpty Dumpty, where at one point,
Humpty Dumpty says "When I use a word, it means just what I
choose it to mean---neither more nor less." When the standard
uses a word, it means just what the standard chooses it to
mean---neither more nor less. The word lvalue is *not* a normal
English word, adopted by the standard; it is an invented word,
whose only definition is in the C and the C++ standards. Except
that neither of them actually define it very well
(intentionally, I suspect). According to the C standard: "Other
terms [than those with explicit definitions in the definitions
section] are defined where they appear in italic type"; C++
says: "Terms that are used only in a small portion of this
International Standard are defined where they are used and
italicized where they are defined." Since neither standard
defines "lvalue" in any definitions section, it is defined where
it is italicized: in C "Anlvalue 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 behavior is
undefined." and in C++ simply "Every expression is either an
lvalue or an rvalue." C++ also adds (in the paragraph following
the definition of lvalue and rvalue, just cited), but not as
part of the definition: "An lvalue refers to an object or
function. Some rvalue expressions—those of (possibly
cv-qualified) class or array type—also refer to objects."

Note that this is true even in C; see my example elsewhere in
this thread. Indexing into an array requires an explicit array
to pointer conversion, resulting in the address of the first
element of the array. One of the changed between C90 and C99 is
that C99 allows this conversion on all arrays, not just lvalue
arrays. So the code in my example is legal in C99, but not in
C90. But that implies obtaining the address of the rvalue in my
example.

and here is the reason (I've looked up the reference I had in
my mind when posting my code): in section 4.9.6 ("Objects and
lvalue") of TC++PL, 3rd edition, B. Stroustrup writes this
line - please note that the citation is _my_ translation of
the Italian text:
"That is, an /object/ is a contiguous region of memory; an
/lvalue/ is an expression with which it is possible to refer
to an object." [emphasis as in the original text]

There's no "if and only if" there. An object is a continuous
region of memory, but not all continuous regions of memory are
objects, and an lvalue is an expression with which it is
possible to refer to an object, but it is not necessarily the
only way to refer to an object. (Be wary of the translation, as
well. In the early French translations of Stroustrup, there
were a lot of cases where the translation said something
significantly different, and in a few cases, contradictory, to
the original text. This is, regretfully, a frequent case for
technical translations.)

I understand that the Italian text could be not perfectly
matching to the original text, but in this very case I think
it expresses the correct meaning - I've found other
definitions in English and they match my translation, as far
as I could understand them.

I'm not saying that the Italian text here is wrong. I'm just
warning you against using Italian versions of technical text
originally written in English, in general. The quality of the
technical translations is often very, very bad. In the case of
Stroustrup translated into French, this was the case in the
early versions, until one of the participants in
fr.comp.lang.c++ went through and made a detailed list of the
errors, with proposed corrections, and Stroustrup intervened
personally with Addison-Wesley to insist that they apply the
corrections. I have no reason to think that the other
translations are any better than the original French
translation, especially in cases where Stroustrup doesn't speak
the language fluently. (Unlike many technical author's,
Stroustrup is very aware of the problem, and will intervene when
necessary.) Anyway, since you obviously can read English
fluently, I'd suggest getting the original English version
whenever possible. (Both Amazon.fr and Amazon.de will sell the
original English versions---at a significantly higher price than
the translations, however: 59,84 Euro vs. 37,99 for Stroustrup's
_The C++ Programming Language__, for example, at Amazon.fr.
Since there's no Amazon.it, and the prices for English books are
significantly lower at Amazon.uk, you could try them. Or shop
around---there are probably a lot of vendors shipping from the
UK.)

 

[Francesco]

    [...]

I understand that a function call is not an lvalue, but I
never said so - but once again I understand that my words
could have been interpreted that way. I meant to say that the
result of that call is a temporary, and I consider the
_temporary_ to be an lvalue, and I consider it to be an lvalue
just because I can get its address. This can be arguable and
will likely be, and eventually I'll be proved wrong. No
problem.

First, very importantly, lvalue is part of the vocabulary of the
standard; it's part of a dialect of English sometimes known as
standardese.  I'd say it was a "Humpty-Dumpty" language, but as
you're not a native English speaker, I'm not sure you'd get the
reference---in Lewis Carroll's _Through the Looking Glass_,
Alice has a discussion with Humpty Dumpty, where at one point,
Humpty Dumpty says "When I use a word, it means just what I
choose it to mean---neither more nor less."  When the standard
uses a word, it means just what the standard chooses it to
mean---neither more nor less.  The word lvalue is *not* a normal
English word, adopted by the standard; it is an invented word,
whose only definition is in the C and the C++ standards.  Except
that neither of them actually define it very well
(intentionally, I suspect).  According to the C standard: "Other
terms [than those with explicit definitions in the definitions
section] are defined where they appear in italic type"; C++
says: "Terms that are used only in a small portion of this
International Standard are defined where they are used and
italicized where they are defined."  Since neither standard
defines "lvalue" in any definitions section, it is defined where
it is italicized: in C "Anlvalue 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 behavior is
undefined." and in C++ simply "Every expression is either an
lvalue or an rvalue."  C++ also adds (in the paragraph following
the definition of lvalue and rvalue, just cited), but not as
part of the definition: "An lvalue refers to an object or
function. Some rvalue expressions—those of (possibly
cv-qualified) class or array type—also refer to objects."

Note that this is true even in C; see my example elsewhere in
this thread.  Indexing into an array requires an explicit array
to pointer conversion, resulting in the address of the first
element of the array.  One of the changed between C90 and C99 is
that C99 allows this conversion on all arrays, not just lvalue
arrays.  So the code in my example is legal in C99, but not in
C90.  But that implies obtaining the address of the rvalue in my
example.

and here is the reason (I've looked up the reference I had in
my mind when posting my code): in section 4.9.6 ("Objects and
lvalue") of TC++PL, 3rd edition, B. Stroustrup writes this
line - please note that the citation is _my_ translation of
the Italian text:
"That is, an /object/ is a contiguous region of memory; an
/lvalue/ is an expression with which it is possible to refer
to an object." [emphasis as in the original text]
There's no "if and only if" there.  An object is a continuous
region of memory, but not all continuous regions of memory are
objects, and an lvalue is an expression with which it is
possible to refer to an object, but it is not necessarily the
only way to refer to an object.  (Be wary of the translation, as
well.  In the early French translations of Stroustrup, there
were a lot of cases where the translation said something
significantly different, and in a few cases, contradictory, to
the original text.  This is, regretfully, a frequent case for
technical translations.)

I understand that the Italian text could be not perfectly
matching to the original text, but in this very case I think
it expresses the correct meaning - I've found other
definitions in English and they match my translation, as far
as I could understand them.

I'm not saying that the Italian text here is wrong.  I'm just
warning you against using Italian versions of technical text
originally written in English, in general.  The quality of the
technical translations is often very, very bad.  In the case of
Stroustrup translated into French, this was the case in the
early versions, until one of the participants in
fr.comp.lang.c++ went through and made a detailed list of the
errors, with proposed corrections, and Stroustrup intervened
personally with Addison-Wesley to insist that they apply the
corrections.  I have no reason to think that the other
translations are any better than the original French
translation, especially in cases where Stroustrup doesn't speak
the language fluently.  (Unlike many technical author's,
Stroustrup is very aware of the problem, and will intervene when
necessary.)  Anyway, since you obviously can read English
fluently, I'd suggest getting the original English version
whenever possible.  (Both Amazon.fr and Amazon.de will sell the
original English versions---at a significantly higher price than
the translations, however: 59,84 Euro vs. 37,99 for Stroustrup's
_The C++ Programming Language__, for example, at Amazon.fr.
Since there's no Amazon.it, and the prices for English books are
significantly lower at Amazon.uk, you could try them.  Or shop
around---there are probably a lot of vendors shipping from the
UK.)

--
James Kanze (GABI Software)             email:[email protected]
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Thank you very much for your in-depth explanation and for your
advices, James, I'll try to get the original English version as soon
as possible.

Have good time,
Francesco