Re: l-values and r-values
On Dec 9, 12:40 am, Taras_96 <taras...@gmail.com> wrote:
I think I mostly understand l-values and r-values after
reading a few archived posts on this board:
* l-values usually appear on the LHS of an assignment, r-values
usually appear on the RHS of an assignment
Historically, that's where the distinction (and the names) come
from. Today, I'd say that the concept is far more arbitrary;
some operators return rvalues, others lvalues and some require
rvalues, others lvalues. And the only real definition of the
terms is the list of these requirements.
An r-value might appear on the LHS of an assignment because of
the following:
* C++ allows a member function to be invoked on a temporary object
* A function returning by value is an r-value
* The assignment operator can be a member function of a UDT
The combination of these factors means that an r-value can
appear on the LHS of an assignment operator:
Yes, because a user defined assignment operator isn't an
assignment operator. Once overload resolution has chosen it,
it is a function call, and it obeys the rules of function calls,
not the rules of assignment operators.
Foo GetTemp() {return Foo;}
GetTemp() = 5; // which is equivalent to
GetTemp.operator=(5); //
You mean
GetTemp().operator=( 5 ) ;
for the second line, of course.
(this of course assumes that the appropriate conversion
constructors and assignment operators are provided for class
Foo)
However, I still don't understand how a string literal can be
considered an l-value.
It's an array, and all arrays are l-values.
The following excerpts hint at an answer:
"String literal: because early C did not have 'const', and so
old C functions that take 'char*' as argument could not be
called with literal strings as actual arguments if string
literals were considered rvalues. However, that may still
change. It's just an old compatibility feature on its way
out" -http://tiny.cc/yEr2A
This has nothing to do with lvalue-ness. In C, the type of a
string literal is char[]. In C++, it is char const[], but there
is a special, limited (and I think deprecated) conversion to
char*, to avoid breaking existing code.
"char *x and char x[] are often used to refer to strings (null
terminated arrays of characters), and they differ in their
"lvalue- ness". " -http://tiny.cc/9JJBG
This is just wrong. In both cases, x is an lvalue. They
differ in type, not in lvalue-ness.
Wouldn't the following:
void foo(char *);
foo("Hello");
be equivalent to:
char * blah = "Hello";
foo(blah);
? I don't see how this effects the l-valueness of a string
literal
Yes, and it doesn't.
Also, is it a defining characteristic of an r-value that you
can not take the address of an r-value (obviously this is true
for most cases, I was wondering if it is, in fact, a defining
characteristic, or whether there are some exceptions)
Well, it's certainly related to the original sense: a lvalue
always designated an object, an rvalue (originally) was just a
value, without an object. In C++, if the rvalue has class type,
then there is an object (and you can obtain its address). Also,
you can initialize a reference to const with an rvalue, and then
take its address. The result is that the distinction
lvalue/rvalue is purely arbitrary.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34