By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,971 Members | 907 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,971 IT Pros & Developers. It's quick & easy.

Questions about chapter 11 (Operator Overloading) of TC++PL.

P: n/a
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". I know that these operators must be nonstatic member
functions, but why this ensure their first operands will be lvalues?
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
oprators.

Best Regards.

Oct 23 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Wayne Shu 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". I know that these operators must be nonstatic member
functions, but why this ensure their first operands will be lvalues?
e.g.
class foo
{
int i;
public:
foo & operator = (int ii) { i = ii; return *this; }
The first operant is ii.
};

foo bar() { return foo(); }

bar() = 10;
here bar() is a rvalue.
The first operant is 10, not bar()
Oct 23 '07 #2

P: n/a
Wayne Shu 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". I know that these operators must be nonstatic member
functions, but why this ensure their first operands will be lvalues?
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.
I'm surprised - I would expect an error in bar() = 10, and there is not.
Additionally, writing

foo & b = (bar() = 10);

it's possible to obtain an lvalue. However, the rvalue obviously can't
be implicitly casted to an lvalue. I'm quizzed.
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
oprators.
I guess that the operator& returns the address of the object, and the
operator= performs a shallow-copy of the object itself.

Regards,

Zeppe
Oct 23 '07 #3

P: n/a
On 10 23 , 5 09 , anon <a...@no.nowrote:
Wayne Shu 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". I know that these operators must be nonstatic member
functions, but why this ensure their first operands will be lvalues?
e.g.
class foo
{
int i;
public:
foo & operator = (int ii) { i = ii; return *this; }

The first operant is ii.
};
foo bar() { return foo(); }
bar() = 10;
here bar() is a rvalue.

The first operant is 10, not bar()
10 is a rvalue too.

Oct 23 '07 #4

P: n/a
Wayne Shu wrote:
On 10 23 , 5 09 , anon <a...@no.nowrote:
>Wayne Shu 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". I know that these operators must be nonstatic member
functions, but why this ensure their first operands will be lvalues?
e.g.
class foo
{
int i;
public:
foo & operator = (int ii) { i = ii; return *this; }

The first operant is ii.
No.
>>
>>};
>>foo bar() { return foo(); }
>>bar() = 10;
here bar() is a rvalue.

The first operant is 10, not bar()
No.
>
10 is a rvalue too.
Yes, but...

To 'anon':

When talking about binary operators (operators with two operands),
the "first" operand is the one that is shown/written to the *left*
when the operator is *being used*. So, when looking at the
expression

a = b

while discussing the assignment operator, 'a' is the _first_
operand and 'b' is the _second_. In C++ it translates so that the
*first* operand is the object for which the function operator= is
called, and the *second* is the actual argument of that function.

In the case above, whatever the subexpression 'bar()' yields would
be the _first_ operand. '10' would be the _second_ operand.

Just making sure we're using the correct terminology.

And, sorry, I don't have the answer to the original question.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 23 '07 #5

P: n/a
On Oct 23, 2:09 pm, anon <a...@no.nowrote:
Wayne Shu 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". I know that these operators must be nonstatic member
functions, but why this ensure their first operands will be lvalues?
e.g.
class foo
{
int i;
public:
foo & operator = (int ii) { i = ii; return *this; }

The first operant is ii.
};
foo bar() { return foo(); }
bar() = 10;
I wonder if this is legal?
The above statement is equivalent to:

bar().operator=(10);

bar() produces a temporary object of type foo. Its member is modified
by the above statement. Is it legal to change the value of temporary
objects created in a full expression, as pre C++ standards?
Some more clarifications are:
Can I evaluate the address of such temporary objects?
I mean, can I do:
std::cout << &bar();

Please give me the relevant sections of C++03 which deals with the
temporary objects created within a full expression.
Thanks in advance for your response.
Oct 23 '07 #6

P: n/a
Rajesh S R wrote:
On Oct 23, 2:09 pm, anon <a...@no.nowrote:
>Wayne Shu 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". I know that these operators must be nonstatic member
functions, but why this ensure their first operands will be lvalues?
e.g.
class foo
{
int i;
public:
foo & operator = (int ii) { i = ii; return *this; }

The first operant is ii.
>>};
>>foo bar() { return foo(); }
>>bar() = 10;

I wonder if this is legal?
The above statement is equivalent to:

bar().operator=(10);

bar() produces a temporary object of type foo. Its member is modified
by the above statement. Is it legal to change the value of temporary
objects created in a full expression, as pre C++ standards?
Yes. Why wouldn't it be legal? A temporary object is not constant.
Some more clarifications are:
Can I evaluate the address of such temporary objects?
No, the address-of operator only applies to lvalues, but you can return
'this' from some member function.
I mean, can I do:
std::cout << &bar();
No, but you can do

class foo {
...
foo& getAddr() { return this; }
};

...
std::cout << bar().getAddr();
Please give me the relevant sections of C++03 which deals with the
temporary objects created within a full expression.
See section 12.2.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 23 '07 #7

P: n/a
"Rajesh S R" <SR**********@gmail.comwrote in message
news:11**********************@q5g2000prf.googlegro ups.com...
On Oct 23, 2:09 pm, anon <a...@no.nowrote:
>Wayne Shu 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". I know that these operators must be nonstatic member
functions, but why this ensure their first operands will be lvalues?
e.g.
class foo
{
int i;
public:
foo & operator = (int ii) { i = ii; return *this; }

The first operant is ii.
};
foo bar() { return foo(); }
bar() = 10;

I wonder if this is legal?
The above statement is equivalent to:

bar().operator=(10);

bar() produces a temporary object of type foo. Its member is modified
by the above statement. Is it legal to change the value of temporary
objects created in a full expression, as pre C++ standards?
Some more clarifications are:
Can I evaluate the address of such temporary objects?
I mean, can I do:
std::cout << &bar();

Please give me the relevant sections of C++03 which deals with the
temporary objects created within a full expression.
I know it is legal to pass a constant reference to a temporary object. I.e.

void Somefunction( const bar& b )
{
}
Somefunction( bar() );

becasue it is ILLEGAL to pass a non constant refernece to a temporary
object.

A temporary object has a lifetime, although it is rather short, generally
one statement. I can't give you chapter and verse, because I don't have a
copy of the standard, but afaik
bar() = 10;
is perfectly legal.
Oct 23 '07 #8

P: n/a
On Oct 23, 10:45 am, Wayne Shu <Wayne...@gmail.comwrote:
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:ja*********@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

Oct 24 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.