Re: how to reuse a copy constructor in an operator = function
James Kanze wrote:
On Nov 2, 10:10 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
JD wrote:
My associate has written a copy constructor for a class.
Now I need to add an operator = to the class. Is there a
way to do it without change her code (copy constructor) at
all? Your help is much appreciated.
First off, why would adding an assignment operator affect the
copy constructor? In fact, you can very likely implement
assignment in terms of the copy-constructor. There are two
methods:
(a) Copy-swap:
T& operator= ( T const & t ) {
T(t).swap( *this );
return ( *this );
}
You need to implement a swap() method for this one.
(b) Destruct-resurrect:
T& operator= ( T const & t ) {
if ( &t != this ) {
this->T::~T();
new (this) T (t);
}
return ( *this );
}
This method has gotchas and is not exception safe and is
therefore not applicable in all cases (but despite the harsh
words that H. Sutter finds about it, it can be justified
sometimes).
It also causes no end of problems if someone inherits from the
class.
(a) That's one of the gotchas, and
(b) the reason for using
this->T::~T();
instead of
this->~T();
That actually takes care of _many_ problems this method can cause in the
context of inheritance.
So far, I only used it in the implementation of a few smart-pointers. In
that case, the self-assignment test can be improved to test for equality of
values, the destructor is non-virtual, and the resulting assignment is
no-throw. Moreover, there is no reason to inherit from those
smart-pointers, ever.
Rule of thumb: generically (and always, when in doubt), go
with (a).
Only if you can implement a no-throw version of swap.
Well, if swap() is no-throw, then (a) is exception safe. But even with a
possibly throwing swap(), it will still do an assignment. You just don't
get the exception safety for the assignment.
Exception safety is not the only reason to use (a) (or (b) for that matter).
The main reason for using one of the two methods above is code-reuse: if
the assignment operation is non-trivial, it is generally much easier to get
it right by defining it in terms of the copy-constructor. E.g., in the
context of reference-counted smart-pointers, it appears to be somewhat
difficult to get the order of count-adjustments right.
Given that method (b) requires too much care, I tend to use (a) in a first
implementation of the assignment operator. Any subsequent change is
considered an optimization.
This is not generally the case, and if swap throws somewhere in the
middle, you may end up with an incoherent state.
Right And the same is true for any other non-exception safe implementation
of the assignment operator.
[snipped: style issue]
In general, of course, the rule for achieving the strong
exception safety guarantee (transactional integrity) is to do
everything that might raise an exception before modifying any
state. But you don't really need the strong guarantee that
often, and meeting it can be expensive.
Actually, I think that your remark from above applies here, too: it is
simply not possible to implement an exception safe assignment operator in
all cases, and there are cases where it is possible but not feasible.
Moreover, I think, the scenarios are more or less the same as for the
no-throw swap() problem: you might need to inherit from a base class beyond
your control, say a library component, and that class does not provide the
necessary means. Also, I have yet to come across a case where an exception
safe assignment is feasible but a non-throwing swap() is not.
Best
Kai-Uwe Bux