Re: reference type methods
On Jul 16, 12:43 am, Ruben <ru...@www2.mrbrklyn.com> wrote:
On Tue, 15 Jul 2008 06:04:43 -0700, James Kanze wrote:
f(x) = 5; //that can't be done
Of course not. A function expression is an lvalue if and
only if its return type is a reference.
Ah - yes.
That's where I started. This is a definition as I see it, not
an implied affect of references.
???
I wouldn't call it a definition; nothing is being defined.
Unless you consider the definition of an lvalue to be the set of
what types of expressions result in one, and what expressions
require one. (And to tell the truth, it's difficult to find any
other definition which really applies.)
My text makes it seem like if a function is defined to return
a reference then simply
.....
class f;
class f(int x){
Something seems garbled here.
public:
f(){
_x = 10;
}
int& g(int x){
_x = x;
return _x;
}
private:
int _x;
};
f him, her;
her.g(5);
him.g = her.g;
What's that supposed to mean?
...BECAUSE him.g is an lvalue of type 'refence',
him.g is an expression having a function type. In this case,
the only thing you can legally do with this expression is call
the function, so whether it is an lvalue or not is completely
irrelevant. The expression him.g() is an lvalue, because f::g
returns a reference. her.g() is an lvalue for the same reason,
although in an expression like "him.g() = her.g()", the lvalue
to rvalue conversion will be immediately applied.
as if the order of operations of the statement would evaluate
the left side of the method g as returning a reference, which
would stand in the functions place which is an lvalue.
It might be an lvalue but if not for some C++ magic syntax
behavior, i'd first expect a type missmatch, as I would if the
return type of g() was a char, or a pointer to array, and then
I returned an int. Secondly, I wouldn't expect the assignment
operator to work anyway!
You've lost me there. "him.g()" is an lvalue. It can be used
on the left side of an assignment (since it is a non-const
lvalue), and you can take its address, "&him.g()", which results
in an int*.
In the case of a the operator[], I thought I might need
another operator overload function called operator[]=
No. All overloaded operators work exactly like normal function
calls, except for the calling sequence (and some details in
overload resolution---in particular, the presence of a member
operator does not hide a global operator).
--
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