Re: canceling noncopyable feature
On Aug 28, 7:56 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
James Kanze wrote:
You lied to the compiler (and to the reader of your code).
First, you said that the object wasn't copiable, then you said
it was. I may be of the old school, but I find lying
despicable.
The simple solution to this problem is to fire the person who
wrote the code.
I'm not sure it's that simple. It can also be a genuine mistake.
Either the class is copiable, or it isn't. If a programmer
can't make up his mind about this, there's a serious problem.
In a long inheritance chain one of the classes buried
somewhere in there might have been made "noncopyable" for some
purpose. Then someone else might inherit from a class
inherited from a class inherited... and so on from that class,
and *inadvertedly* write a copy constructor for it, overriding
the one in that "noncopyable" class.
One can wonder about the wisdom of a long inheritance chain, but
that's not the issue. A derived class is free to offer
additional functionality, including copy, compared to what the
base class offers. I don't see where there's a problem. The
problem is if the author of the base class says both
not-copiable and copiable at the same time.
(Obviously, the derived class can only offer new functionality
if it is capable of implementing it correctly; if the base class
contains data, the derived class probably cannot implement copy
correctly. But in most cases, base classes are interfaces which
don't contain data, so this is often not a problem.)
Of course for this to compile this person has to, if I
understood correctly, fail to call the parent class copy
constructor in his own. Of course this is a bad mistake in
itself, but it might happen.
It depends. I'd guess that most of the time my derived classes
offer copy, they don't call the base class copy constructor,
since the base class is typically abstract, without data, and
doesn't guarantee copy.
The problem is that now, by pure accident, the class has
become copyable even though it should not be,
Should it, or should it not be copiable, that is the question.
The author of the derived class must know this---it's a design
decision. If it should be copiable, he'll have to implement a
copy constructor with the desired semantics. If it shouldn't,
and he implements a copy constructor, there's a serious problem.
and the compiler is of no help in catching this.
How can it be? The compiler doesn't know the intent or the
design of the class.
--
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