Re: rvalues, lvalues, Comeau
Kyle wrote:
Consider code below, which i have tested with Comeau online compiler:
<code>
struct A {
int tab[5];
};
struct B {
A tab[5];
};
B foo() {
B b;
return b;
}
int main() {
/*
foo() returns a value so 'foo()' is an rvalue, and thus 'foo().tab' is
rvalue as well, so the code shoud be rejected
*/
A (&tab1)[5] = foo().tab; //(1)this code is rejected
/*
below situation is the same and the expression on the right side is also
rvalue
*/
int (&tab2)[5] = foo().tab[0].tab; //(2)this code is however accepted
}
</code>
Now, is it Comeau that gets confused with the second expression, or
perhaps i misunderstood something and 'foo().tab[0].tab' yields lvalue ?
I think it is the language itself which is confused:-).
'foo().tab[0].tab' is the equivalent of '(*(foo().tab+0)).tab';
the results of the unary * are always an lvalue (by definition),
and the results of the . operator are an lvalue if the left
operand is an lvalue.
The result is, of course, rather ridiculous. Normally, you
can't get the address of an rvalue, in order to apply [] to it,
but the implicit conversion of array to pointer works on
rvalues, and so you do end up with a pointer to an rvalue.
The whole way C style arrays are handled always reminds me of a
quote from Walter Scott: "Oh what a tangled web we weave, When
first we practise to deceive!"
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]