Re: Questions about chapter 11 (Operator Overloading) of TC++PL.
On Oct 23, 10:45 am, Wayne Shu <Wayne...@gmail.com> wrote:
Hi everyone, I am reading B.S. 's TC++PL (special edition).
When I read chapter 11 Operator Overloading, I have two questions.
1. In subsection 11.2.2 paragraph 1, B.S. wrote "In particular,
operator =, operator[], operator(), and operator-> must be nonstatic
member function; this ensures that their first operands will be
lvalues".
This is wrong. User defined operators obey the semantics of
function calls, once operator overload resolution has chosen
them. And you can call a function on an rvalue. This is also
true for operator= which the compiler implicitly generates; that
operator is also a function, and obeys the semantics of function
calls.
I'm not sure I understand the statement anyway: there's no
requirement anywhere that the first operand of ->, () or [] be
an lvalue, even for the built in operators. Expressions like:
MyType* p = new MyType[ 2 ] ;
(p+1)->f() ;
,
extern void (*getPF)() ;
(getPF())() ;
or
int ** p = new int[ 10 ][ 10 ] ;
(p+1)[2] ;
are legal, although the first operand is not an lvalue.
The only time an lvalue is required is for a built-in operator
which is specified to require it. There's no way you can impose
the same restriction on a user defined operator. For class
types, off hand, the only built-in operator which requires an
lvalue is, I think, the unary & (address of)---if you overload
it (e.g. to return this), then you can take the address of an
rvalue as well.
In fact, if you want to implement an operator in a way that
requires an lvalue, you have to make it a non-member, with a non
const reference as the first parameter. Consider:
class A { public: A& operator+=( A const& other ) ; } ;
class B {} ;
B& operator+=( B& lhs, B const& rhs ) ;
The += operator of A does not require an lvalue; the += operator
of B does.
(Stroustrup was probably thinking of something else when he
wrote that sentence. Supposing you have quoted him correctly,
of course.)
I know that these operators must be nonstatic member
functions, but why this ensure their first operands will be
lvalues?
It doesn't.
e.g.
class foo
{
int i;
public:
foo & operator = (int ii) { i = ii; return *this; }
};
foo bar() { return foo(); }
bar() = 10;
here bar() is a rvalue.
2. also in subsection 11.2.2, paragraph 3, "Because of historical
accident, the operators = (assignment), & (addressof), and ,
(sequencing) have predefined meanings when applied to class objects.",
I want to know the mentioned predefined meanings of the these
operators.
First, operator= is slightly different from the other two.
Formally, the other two are built in operators which can be
applied to expressions of any type; there is no built in
operator= for class types, but rather the compiler synthesizes
a copy operator= function if you fail to provide one. (Note
that the compiler synthesizes a function declaration, which
participates in operator overloading just like any other
function, and in some bizarre cases, may not even be chosen.)
The semantics of the compiler generated copy assignment operator
are member by member copy assignment; the copy assignment
operator is called for each base class and each member.
The semantics of the built-in address of and comma operators are
the same for all objects, regardless of type. The built-in
address of operator (unary &) requires an lvalue, and returns
the address of the corresponding object. The built-in comma
operator simply means that the first operand is evaluated, its
value ignored (but any side effects do take place), and then the
second operand is evaluated. (It's very useful for obfuscation.
Overloading it is even more useful for obfuscation---and not
much else.)
--
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