operator = overloading...

[Rahul]

Hi Everyone,

I was overloading the operator= function as a class member function,

#include <iostream.h>

class A
{
int value;
public : A& operator = (const A& ref)
{
this->value = ref.value;
cout<<"in"<<end l;
return *this;
}
A(int value) : value(value)
{
}
A(const A& copy)
{
this->value = copy.value;
cout<<"copy with a value of "<<copy.value<< endl;
}
void print()
{
cout<<"value is"<<value<<end l;
}
};

int main()
{
A obj(0);
A obj1(10);
A obj2(20);
obj.print();
obj1.print();
obj2.print();
obj1 = obj = obj2;
obj.print();
obj.print();
obj2.print();
}

It works fine and all objects have a value of 20 as expected...

Next i changed the return type of the operator = function, like
so that it returns an object instead of a reference...

A operator = (const A& ref)
{
this->value = ref.value;
cout<<"in"<<end l;
return *this;
}

And as the object is returned by value, each call to operator= also
invokes the copy constructor for the temp object, which is again
passed to the operator= function, and the end result happens to be
same as with operator= function which returns a reference.

Is there any thumb rule while overloading operators, when we have
alternative implementations ?

Thanks in advance!!!

[Craig Scott]

Re: operator = overloading...

On Dec 20, 6:43 pm, Rahul <sam_...@yahoo. co.inwrote:

Is there any thumb rule while overloading operators, when we have
alternative implementations ?

Yes. Member operators are generally expected to return a reference to
themselves (at least, that's my undestanding). This provides the
expected behaviour when chaining operators. For example:

MyClass a, b, c;
// Presumably do stuff with c here, then.....
a = b = c;

No extra copies are involved when operator=() returns by reference.

--
Computational Modeling, CSIRO (CMIS)
Melbourne, Australia

Why do you want to return by value from operator=()?

[Rahul]

Re: operator = overloading...

On Dec 20, 1:52 pm, Craig Scott <audiofana...@g mail.comwrote:

On Dec 20, 6:43 pm, Rahul <sam_...@yahoo. co.inwrote:
>

Is there any thumb rule while overloading operators, when we have
alternative implementations ?

>
Yes. Member operators are generally expected to return a reference to
themselves (at least, that's my undestanding). This provides the
expected behaviour when chaining operators. For example:
>
MyClass a, b, c;
// Presumably do stuff with c here, then.....
a = b = c;
>
No extra copies are involved when operator=() returns by reference.
>
--
Computational Modeling, CSIRO (CMIS)
Melbourne, Australia
>
Why do you want to return by value from operator=()?

But the chaining works even when operator= returns a copy too...

[Kira Yamato]

Re: operator = overloading...

On 2007-12-20 02:43:29 -0500, Rahul <sam_cit@yahoo. co.insaid:

Hi Everyone,
>
I was overloading the operator= function as a class member function,
>
#include <iostream.h>
>
class A
{
int value;
public : A& operator = (const A& ref)
{
this->value = ref.value;
cout<<"in"<<end l;
return *this;
}
A(int value) : value(value)
{
}
A(const A& copy)
{
this->value = copy.value;
cout<<"copy with a value of "<<copy.value<< endl;
}
void print()
{
cout<<"value is"<<value<<end l;
}
};
>
int main()
{
A obj(0);
A obj1(10);
A obj2(20);
obj.print();
obj1.print();
obj2.print();
obj1 = obj = obj2;
obj.print();
obj.print();
obj2.print();
}
>
It works fine and all objects have a value of 20 as expected...
>
Next i changed the return type of the operator = function, like
so that it returns an object instead of a reference...
>
A operator = (const A& ref)
{
this->value = ref.value;
cout<<"in"<<end l;
return *this;
}
>
And as the object is returned by value, each call to operator= also
invokes the copy constructor for the temp object, which is again
passed to the operator= function, and the end result happens to be
same as with operator= function which returns a reference.
>
Is there any thumb rule while overloading operators, when we have
alternative implementations ?
>
Thanks in advance!!!

I can't see any legitimate situation where you would prefer to return a
value instead of a reference here.

So, I would say, between those two options, always choose return by
reference since it avoids a copy constructor invocation.

--

-kira

[James Kanze]

Re: operator = overloading...

On Dec 20, 10:40 am, Kira Yamato <kira...@earthl ink.netwrote:

On 2007-12-20 02:43:29 -0500, Rahul <sam_...@yahoo. co.insaid:

[...]

Is there any thumb rule while overloading operators, when we
have alternative implementations ?

Thanks in advance!!!

I can't see any legitimate situation where you would prefer to
return a value instead of a reference here.

So, I would say, between those two options, always choose
return by reference since it avoids a copy constructor
invocation.

The general rule is to be as much like the built-in operators as
possible. This basically means that if the built-in operator is
an lvalue, return a reference, and if it is not, return a value.
Since = (and all of the <op>=) are lvalues, you return a
reference.

Note too that if there are implicit conversions to the data
type, you probably want the operators which don't require an
lvalue to be non-members.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Kira Yamato]

Re: operator = overloading...

On 2007-12-20 04:49:53 -0500, James Kanze <james.kanze@gm ail.comsaid:

On Dec 20, 10:40 am, Kira Yamato <kira...@earthl ink.netwrote:

>On 2007-12-20 02:43:29 -0500, Rahul <sam_...@yahoo. co.insaid:

>
[...]

>>Is there any thumb rule while overloading operators, when we
>>have alternative implementations ?

>

>>Thanks in advance!!!

>

>I can't see any legitimate situation where you would prefer to
>return a value instead of a reference here.

>

>So, I would say, between those two options, always choose
>return by reference since it avoids a copy constructor
>invocation.

>
The general rule is to be as much like the built-in operators as
possible. This basically means that if the built-in operator is
an lvalue, return a reference, and if it is not, return a value.
Since = (and all of the <op>=) are lvalues, you return a
reference.
>
Note too that if there are implicit conversions to the data
type, you probably want the operators which don't require an
lvalue to be non-members.

Can a temporary object be an lvalue? The following code compiles fine
under g++ 4.0.1:

int main()
{
class T {};
T() = T();
return 0;
}

--

-kira

[James Kanze]

Re: operator = overloading...

On Dec 20, 11:53 am, Kira Yamato <kira...@earthl ink.netwrote:

On 2007-12-20 04:49:53 -0500, James Kanze
<james.ka...@gm ail.comsaid:

On Dec 20, 10:40 am, Kira Yamato <kira...@earthl ink.netwrote:

On 2007-12-20 02:43:29 -0500, Rahul <sam_...@yahoo. co.insaid:

[...]

>Is there any thumb rule while overloading operators, when we
>have alternative implementations ?

>Thanks in advance!!!

I can't see any legitimate situation where you would prefer to
return a value instead of a reference here.

So, I would say, between those two options, always choose
return by reference since it avoids a copy constructor
invocation.

The general rule is to be as much like the built-in operators as
possible. This basically means that if the built-in operator is
an lvalue, return a reference, and if it is not, return a value.
Since = (and all of the <op>=) are lvalues, you return a
reference.

Note too that if there are implicit conversions to the data
type, you probably want the operators which don't require an
lvalue to be non-members.

Can a temporary object be an lvalue?

Not normally. The standard doesn't actually make an explicit
equivalence, but most of the cases listed in §12.2 where a
temporary comes into existence involve expressions which are
rvalues.

The following code compiles fine under g++ 4.0.1:

int main()
{
class T {};
T() = T();
return 0;
}

Yes. The reason is that there is no problem calling a member
function on a temporary, and for class types, operator= is a
member function.

To return to my initial point: there is no way to restrict a
user defined operator to lvalues. By making it a member,
however, you do prevent conversions: built-in operators
which require lvalues will not accept the results of
conversions, and those that do not require lvalues do.

At least, that's the commonly accepted point of view. On
thinking about it, however: if you define something like
operator+= as a non-member (friend), then the first argument
will be a non-const reference (otherwise you cannot possibly
give it the semantics it should have). And you can't initialize
a non-const reference with a temporary. Which would argue for
making operators requiring an lvalue free functions, and not
members. (Except for operator=, which for other reasons cannot
be a free function.)

Note that the issue is far from moot. Suppose you want an
iterator to the last element in a container you know is not
empty, and that has at least a bidirectional iterator (e.g. any
of the standard sequences). You might be tempted to write:
-- container.end()
. If the operator-- function of the iterator is a member (which
it is in most, if not all, current implementations ), this works.
If it is not (or if the "iterator" is just a typedef for a
pointer, which was the case in a lot of early implementations of
std::vector), then it doesn't. (Since the abstraction of STL
iterators is a pointer, we'd really like for it not to work.)

So it's worth thinking about, even if the currently accepted
best practice is as I originally stated: that operators which
require lvalues be members, and operators that don't be free
functions. (And of course, when you deviate from currently
accepted best practices, aka the standard way of doing things,
you raise questions in your readers' minds. It's better not to
without very strong reasons.)

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Kira Yamato]

Re: operator = overloading...

On 2007-12-21 04:27:06 -0500, James Kanze <james.kanze@gm ail.comsaid:

On Dec 20, 11:53 am, Kira Yamato <kira...@earthl ink.netwrote:

>On 2007-12-20 04:49:53 -0500, James Kanze
><james.ka...@g mail.comsaid:

>

>>On Dec 20, 10:40 am, Kira Yamato <kira...@earthl ink.netwrote:
>>>On 2007-12-20 02:43:29 -0500, Rahul <sam_...@yahoo. co.insaid:

>

>>[...]
>>>>Is there any thumb rule while overloading operators, when we
>>>>have alternative implementations ?

>

>>>>Thanks in advance!!!

>

>>>I can't see any legitimate situation where you would prefer to
>>>return a value instead of a reference here.

>

>>>So, I would say, between those two options, always choose
>>>return by reference since it avoids a copy constructor
>>>invocation .

>

>>The general rule is to be as much like the built-in operators as
>>possible. This basically means that if the built-in operator is
>>an lvalue, return a reference, and if it is not, return a value.
>>Since = (and all of the <op>=) are lvalues, you return a
>>reference.

>

>>Note too that if there are implicit conversions to the data
>>type, you probably want the operators which don't require an
>>lvalue to be non-members.

>

>Can a temporary object be an lvalue?

>
Not normally. The standard doesn't actually make an explicit
equivalence, but most of the cases listed in §12.2 where a
temporary comes into existence involve expressions which are
rvalues.
>

>The following code compiles fine under g++ 4.0.1:

>

>int main()
>{
>class T {};
>T() = T();
>return 0;
>}

>
Yes. The reason is that there is no problem calling a member
function on a temporary, and for class types, operator= is a
member function.
>
To return to my initial point: there is no way to restrict a
user defined operator to lvalues. By making it a member,
however, you do prevent conversions: built-in operators
which require lvalues will not accept the results of
conversions, and those that do not require lvalues do.
>
At least, that's the commonly accepted point of view. On
thinking about it, however: if you define something like
operator+= as a non-member (friend), then the first argument
will be a non-const reference (otherwise you cannot possibly
give it the semantics it should have). And you can't initialize
a non-const reference with a temporary. Which would argue for
making operators requiring an lvalue free functions, and not
members. (Except for operator=, which for other reasons cannot
be a free function.)
>
Note that the issue is far from moot. Suppose you want an
iterator to the last element in a container you know is not
empty, and that has at least a bidirectional iterator (e.g. any
of the standard sequences). You might be tempted to write:
-- container.end()
. If the operator-- function of the iterator is a member (which
it is in most, if not all, current implementations ), this works.
If it is not (or if the "iterator" is just a typedef for a
pointer, which was the case in a lot of early implementations of
std::vector), then it doesn't. (Since the abstraction of STL
iterators is a pointer, we'd really like for it not to work.)
>
So it's worth thinking about, even if the currently accepted
best practice is as I originally stated: that operators which
require lvalues be members, and operators that don't be free
functions. (And of course, when you deviate from currently
accepted best practices, aka the standard way of doing things,
you raise questions in your readers' minds. It's better not to
without very strong reasons.)

Very interesting read.

So, this is telling me that we should do things in your suggested way:
that is, declare operators that should require lvalues be free
functions and declare its first parameter a non-const reference.

Well, even if it is not standard practice, I'll start doing that.

--

-kira