Re: C++ Primer 4th edition Reference Counting Smart Pointers
On Jul 1, 8:38 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
James Kanze wrote:
Objects which are dynamically allocated do not normally support
assignment. But it doesn't matter: the required base class for
the intrusive reference counter declares both the copy
constructor and the assignment operator private;
You have mentioned that before, and I still don't get it.
The main reason I allocate objects dynamically, rather than
copying them, is polymorphism. Polymorphism and assignment
don't work well together.
The correct solution to the problem is to create an empty copy
constructor and assignment operator in the base class (ie.
they simply do nothing). After that, assigning objects around
will not mess up the reference count.
That's another possibility. In my case, I find that almost none
of my reference counted objects are copiable or assignable---if
they were, I wouldn't be allocating them dynamically to begin
with. So the more reasonable solution seems to be to ban copy
and assignment in the required base class. If the derived class
really wants to provided it (e.g. to support cloning), all it
has to do is write a copy constructor or an assignment operator
which doesn't invoke the ones in the base class.
That solution is very simple and obvious (once you know it).
I considered it, and decided that blocking them was preferable.
But either is really OK.
However, instead of that, you prefer to write about the exact
same amount of code just to make the copy constructor and
assignment operator private. For what end? To make the user's
life more difficult for no apparent purpose?
It makes the client code simpler, since classes which derive
from this base class no longer have to inhibit copy and
assignment themselves.
--
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