Re: operator = overloading...
On Dec 20, 11:53 am, Kira Yamato <kira...@earthlink.net> wrote:
On 2007-12-20 04:49:53 -0500, James Kanze
<james.ka...@gmail.com> said:
On Dec 20, 10:40 am, Kira Yamato <kira...@earthlink.net> wrote:
On 2007-12-20 02:43:29 -0500, Rahul <sam_...@yahoo.co.in> 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 =A712.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.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