Richard Heathfield <in*****@invalid.invalidwrites:
Andrey Tarasevich said:
>Frederick Gotham wrote:
>>...
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.
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>
--
Keith Thompson (The_Other_Keith)
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.