* Victor Bazarov:
So, you're saying that the question "are all temporaries rvalues" is not
really valid?
Yes, it's an invalid question, because the concept of rvalue-ness doesn't apply
to temporaries.
On the other hand, most temporaries are produced by rvalue expressions, so there
is a close association.
But on the third hand, many rvalue expressions, e.g. 2+2, do not (necessarily)
produce temporaries.
An rvalue is a concept, a result of an expression *or*
something an operator (like built-in unary + or -) expects. We can use
temporaries wherever an rvalue is expected, which means the temporary
will be evaluated, converted, whatever, to become the rvalue. And
sometimes when we get an rvalue as the result of some expression, there
is also a temporary close-by...
Slippery, aren't they?
Yes, but for other reasons.
The standard starts out, in §3.10/1, by saying that "Every expression is either
an lvalue or an rvalue".
It then explains that an lvalue expression /refers/ to an object or function,
and that some rvalue expressions, namely those of class type, can also refer to
objects.
And so it goes on, into details, e.g. that the result of a function call that
does not return a reference, is an rvalue (this particular statement seems a bit
ungood to me, talking about the "result" of the call and implicitly defining
foo(), where foo is a function returning void, as an rvalue expression, i.e. you
can have an rvalue expression that doesn't even denote a value).
A way to understand it is to consider the C origins of the language. In original
C an rvalue (implicitly defined as "not lvalue") was simply a value, as opposed
to an expression referring to something (like dereferencing a pointer). The
introduction of ability to return structures in C (I guess we're then up to K&R
C) possibly made this a little more complicated, I'm not sure what the exact C
rules are for that, but anyway still not very complicated.
In C++, with implicitly defined operators for class types, and where member
routines can be called on rvalue expressions, it gets really complicated. It's a
too narrow concept enforced on the language for conceptual C compatibility.
E.g., as you've seen before, but I think of interest to the OP,
struct S { int x; S( int xVal ): x( xVal ) {} };
S f() { return S( 0 ); }
int main()
{
f() = S(42); // OK, because we have an implicit S:
perator=
f().x = 666; // Nope, can't assign to rvalue of basic type.
}
although some compilers will accept the latter assignment.
Cheers,
- Alf
