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"<<endl;
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<<endl;
}
};

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"<<endl;
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]

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.

 

[Rahul]

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]

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"<<endl;
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<<endl;
}
};

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"<<endl;
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.

 

[James Kanze]

On 2007-12-20 02:43:29 -0500, Rahul <[email protected]> said:

[...]

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.

 

[Kira Yamato]

On 2007-12-20 02:43:29 -0500, Rahul <[email protected]> said:
[...]

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;
}

 

[siddhu]

On 2007-12-20 02:43:29 -0500, Rahul <[email protected]> said:

[...]
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- Hide quoted text -

- Show quoted text -

For user defined types temporaries can be lvalue. But its useless. So
whenever you return by value ,try to return it as const value in order
to make it consistent with POD types.

I have a question.

obj = obj1 = obj2;

In the above statement what is the order of calling of assignment
operators? I think standard does not specify any order. please
clarify.

 

[Victor Bazarov]

[..]
I have a question.

obj = obj1 = obj2;

In the above statement what is the order of calling of assignment
operators? I think standard does not specify any order. please
clarify.

Yes, it does. Associativity of assignment operators is right-to-left.
That means the expression is evaluated as if it is written as

obj = (obj1 = obj2);

V

 

[siddhu]

[..]
I have a question.

obj = obj1 = obj2;

In the above statement what is the order of calling of assignment
operators? I think standard does not specify any order. please
clarify.

Yes, it does. Associativity of assignment operators is right-to-left.
That means the expression is evaluated as if it is written as

obj = (obj1 = obj2);

So how does chaining come into play?

 

[Rahul]

[..]
I have a question.
obj = obj1 = obj2;
In the above statement what is the order of calling of assignment
operators? I think standard does not specify any order. please
clarify.

Yes, it does. Associativity of assignment operators is right-to-left.
That means the expression is evaluated as if it is written as

obj = (obj1 = obj2);

So how does chaining come into play?

V

It is as good as saying,
obj.operator=(obj1.operator=(obj2))

 

[James Kanze]

On 2007-12-20 04:49:53 -0500, James Kanze
<[email protected]> said:

On 2007-12-20 02:43:29 -0500, Rahul <[email protected]> said:

[...]

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]

On Dec 20, 5:53 am, Kira Yamato <[email protected]> wrote:

[...]

For user defined types temporaries can be lvalue.

No. For class types, an rvalue is an object: it has an address,
and a cv-qualified type. (For non-class types, an rvalue does
not have an address, and the type is always non cv-qualified.
Although if it results in a temporary, trying to modify it is
undefined behavior, even if it isn't const.)

FWIW: at various times, different experts have suggested that
functions or operators returning class types should declare them
const, e.g.:
MyClass const operator+( MyClass const& lhs,
MyClass const& rhs ) ;
This would prevent calling non-const functions on them, e.g.
(a + b) = x ;
would be illegal, because operator= is a non-const function.
This recommendation doesn't seem to have caught on, however,
perhaps because there's no way to make it cover the case in your
example---there is no way to explicitly create a const
temporary.

But its useless. So whenever you return by value ,try to
return it as const value in order to make it consistent with
POD types.

It's still not really consistent, since class type rvalues do
have different behavior than non-class type rvalues. It's just
less inconsistent (and abouty the best you can do).

As I said, you're not the first to recommend this. (I think
Scott Meyers recommends it as well.) But it doesn't seem to be
happening.

I have a question.

obj = obj1 = obj2;

In the above statement what is the order of calling of
assignment operators? I think standard does not specify any
order. please clarify.

The standard specifies a binding: obj is assigned the results of
the expression (obj1 = obj2). In the case of user defined types
(where the operator= is a function, and introduces sequence
points), this imposes an actual order. In the case of the
built-in operator=, however, the order in which obj and obj1 are
modified is not specified (although the value assigned to obj
must be the value that is assigned to obj1, and not the original
value of obj2). There is, of course, no way you could tell in a
standard conforming program, but if you look at the generated
code, or place watch points in a debugger, you could. (The
order could also, in theory, be observable in a multithreaded
environment. But in all the multithreaded environments I know,
if you haven't serialized all accesses to obj and obj1 by some
external locking mechanism, then the program has undefined
behavior anyway.)

 

[Kira Yamato]

On 2007-12-20 04:49:53 -0500, James Kanze
<[email protected]> said:

On 2007-12-20 02:43:29 -0500, Rahul <[email protected]> said:
[...]
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.