Re: how to reuse a copy constructor in an operator = function
On Nov 5, 11:03 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
[...]
Thank you very much for the detailed explanation. I wasn't
aware of that. Now I see that you were right from the
beginning: the destroy-resurrect thingy can only be done for
final classes (of which there are virtually none.)
The real rule is that once it appears in a hierarchy, *all*
further derived classes must use it exclusively. Which means
that even the most trivially derived class requires a user
defined assignment operator. Document it as you will, some one
is going to forget.
The main point of destroy-resurrect is code-reuse.
I understand that. I stumbled on the same idea something like
15 years ago. Got taken down by Steve Clamage, and had to admit
that his arguments were justified. (And that was before
exceptions.) In my case, the goal was to ensure correct
behavior in the case of virtual inheritance (where the
intermediate classes can't call the base's operator= directly
without risking it being called several times). So I couldn't
even use the argument that inheritance didn't make sense for the
types I was using it for.
I hope, the following variation achieves that effect legally
and without undefined behavior:
class X {
void release ( void ) {
// release all resources;
}
public:
X & operator= ( X const & other ) {
if ( this != &other ) {
release();
// allocate resources and reassign members
}
return ( *this );
}
X ( X const & other ) {
this->operator= ( other );
}
~X ( void ) {
release();
}
};
It has the disadvantage that the copy-constructor will now use
assignment instead of initialization, which means that the
members will have to be default-constructed. Alas.
G++ used something similar in their older versions of
std::string; always construct an empty string, and go on from
there using assignment. Depending on the actual class, it could
be a reasonable solution. (If the class involves dynamic
memory, and the constructors all set the pointer to null first,
for example.)
[snip]
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.
Nor any other benefits.
What other benefits do you expect from an assignment operator?
I'm talking about the swap idiom: if I use a particular idiom,
it's because I expect some benefit from doing so. If all of the
sub-objects have a no-throw, relativly optimized swap, that's no
problem with the swap idiom because the benefits greatly
outweigh the cost. But if some subclass doesn't implement it,
then I'm not really implementing the swap idiom; I'm
implementing something that looks like it, but that isn't. I'm
confusing the reader (who recognizes the idiom, and assumes
something that isn't true), and I'm likely paying an unnecessary
performance penalty.
You'r engaged in premature optimization :-)
I was afraid someone was going to say that.
If copy/swap were the established idiom for *all* assignment
operators, then there would be some truth to it, as well. The
real argument is that I just don't expect to see it unless it is
guaranteeing exception safety.
And of course, if you do end up using std::swap on one of the
sub-elements, you've copied it an awful lot of times (3 or 4,
rather than just one).
I guess it's a matter of how copy-swap is advertised. To me,
exception safety is only one of the reasons to go with
copy-swap, and it does not always apply. I see that copy-swap
by and in itself does not make the assignment operator
exception safe. What it does is propagating exception safety
from members and base classes to the class under
consideration. If one of the subobjects breaks the chain, all
exception safety is lost. (I am probably as guilty as others
of not stressing that point clear when talking about
copy-swap).
The important point (with regards to exception safety) is that
none of the swap functions can throw. In particular, *if* you
have a member of class type which does not have a swap member
function, you cannot expect the exception safety guarantees if
you use std::swap to swap it; std::swap will use the copy
constructor and the assignment operator.
To me, however, the main benefit of copy-swap is that it is
simpler to get a swap() right than an assignment operator
(since you only have to move resources around, no release of
resources is required). Also, a swap requires usually less
code than an assignment operator (which sort of combines lines
from the destructor and from the copy-constructor). Whenever I
want a swap method (and I usually do since I alway have
classes that represent values), I have the strong inclination
of writing the assignment operator in 3 lines and be done with
it. There is nothing wrong in saving brain cycles. The CPU can
easily make up for it, and if it can't, then I optimize what
is needed.
*If* I can furnish an effective swap function, then I certainly
do use it in the assignment operator. My criticism is more
along the lines that unless all of your class type sub-objects
have furnished an effective swap function, you generally can't
either.
With regard to the "confusing the reader" point: the copy-swap
idiom will only trick those into false expectations who think
that exception safety is its main point. Whether that applies
to a certain community, is a cultural thing. Of course, if
your teammates have that opinion, you are well-advised to code
accordingly. And you maybe right that in most places the
expectation would be that copy-swap indicates exception
safety.
Well, it applies to me. Perhaps because I was writing
complicated assignment operators long before the swap idiom
became current, or because I still have to deal with a lot of
code which doesn't support it.
But seriously, if you were implementing something like
std::complex, would you use the swap idiom?
--
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