Re: how to reuse a copy constructor in an operator = function
On Nov 4, 1:11 am, Elias Salom=E3o Helou Neto <eshn...@gmail.com> wrote:
On 3 nov, 06:58, James Kanze <james.ka...@gmail.com> wrote:
On Nov 2, 10:30 pm, Elias Salom=E3o Helou Neto <eshn...@gmail.com>
wrote:
[...]
MyClass& MyClass::operator=( const MyClass& rhs )
{
MyClass temp( rhs ); //Reusing copy constructor code.
this->swap( temp );
return( *this );
}
Notice that this may be sub-optimal because some instructions
in the copy constructor will be much the same than some in the
swap() method.
It may be sub-optimal, because the normal implementation of swap
will invoke the assignment operator. Infinite recursion is
definitely sub-optimal. Obviously, you need a special
implementation of the swap function, which doesn't use the
assignment operator. In practice, this idiom is only useful if
all of the sub-elements support a no-throw swap. This is the
case for the containers in the standard library, and should be
the case for most new code, provided the authors have kept
themselves up to date, but there is an awful lot of code
floating around where it is not the case.
Even if the assignement operator (for the actual class) is not
used in the swap member (and it cannot be, because it does not
exist, remeber?),
Well, the thing that worries me most is someone implementing a
member swap function:
void
MyClass::MyClass( MyClass& other )
{
std::swap( *this, other ) ;
}
If the only goal is to provide the class with a swap function,
this is the obvious way to do it. Use this function in the
assignment operator, however, and you're going to have a real
performance problem---the operator will only stop when it runs
out of stack.
this will be sub-optimal because many fields will be assigned
(with their assignement operator) in the copy constructor,
only to be reassigned then, via the swap member. With a
straightforward (without trying to reuse the copy constructor)
implementation of operator= this would not be needed. I was
not even thinking about infinite recursion.
Even without infinite recursion, I agree. In general, I will
take the risk that if the class type of a sub-element provides a
member swap, it will be more efficient to use it; my rule is to
use the swap idiom only if the class consists only of class
types with a member swap function or non-class types.
If one could assign to the this pointer, things could be made
easier, even without that swap() method.
You'll have to explain that one to me. Assigning to the this
pointer would be tandamount to moving the object somewhere else
in memory, no?
Somehow, yes.
This raises the question: why isn't the this pointer a valid
lvalue?
Because it doesn't make sense to make it one. What would it
mean if you changed the value of the this pointer?
It does make sense: I could change the this pointer to point
to another object of the same (or even derived) classes,
without the placement new hassle.
But what does this do for you. The object (in memory) I called
the function on isn't going anywhere, and all of the users of
the object will still look for it in the old place.
Placement new, as I see, is meant to be used to
ensure correct placement of the object when it is needed.
For example. The important point about placement new is that
the address is being supplied by the caller. He's putting the
object where he expects it. You can't change where the caller
expects to find the object from inside the function.
In this case it ended up being used as a workaround because
this is not an lvalue (not quite that, keep on reading). Would
not the case (b) from Kai-Uwe Bux be better if written like
the following?
T& T::operator= ( T const & t ) {
T *copy = new T( *this ); //Reuses copy ctr.
T *temp;
temp = this;
this = copy; //Not c++!
delete temp;
return ( *this );
}
The main issue here is that it would invalidate any pointer/reference
to the object,
And since to call the operator, you definitly had such a
pointer, or at least knew its address, and since you wouldn't
bother calling such a function unless you were going to use the
object again...
Think of what happens in the case of:
T anObject ;
anObject = someOtherT ;
and it is definitely dangerous. If this is the case for your
class (and it will be to most classes), Kai-Uwe Buxs solution
is definitely better, even if not perfect.
Kai-Uwe's solution doesn't really work either.
The point is that in some, though rare, cases assigning to the
this pointer makes sense. It would, however, be extremely
dangerous and perhaps the standard is right about avoiding it.
It doesn't make any sense with the C++ object model. It's hard
to see how the object model could be rewritten so that it would
make sense. In the C++ object model, an object is identified by
its address. Change the address, and you have a different
object.
--
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