Re: canceling noncopyable feature
On Aug 27, 8:25 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
mzdude wrote:
On Aug 27, 11:55 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
Fraser Ross wrote:
Thats a big problem. noncopyable doesn't do its job as
well as I thought.
It doesn't necessarily means that it's not doing its job
*as intended*, and what you thought isn't necessarily what
was intended. What do you think it would do? Make any
descendant class non-copyable?
Yes. Perhaps changing the boost::noncopyable object to hide
it's default ctor would help.
Then if you have a class derrived from it
class MyClass : boost::noncopyable
{
MyClass() : boost::noncopyable( some_trait ) {}
// then
MyClass( const MyClass &tocpy ) {}
would error because the compiler would subsitute the default
ctor for noncopyable which would be hidden.
I don't think that noncopyable is meant to keep you from
blowing your brains out. It's meant to be a somewhat language
enforced method of documenting a known aspect of an interface.
Anything that derives from noncopyable is not meant to be
copied, that's what the relationship is documenting.
I'd agree if you restrict it to directly deriving. When you
derive from boost::noncopyable, you're saying that copying is
*not* allowed. According to the LSP, however, a class which
derives from MyClass, above, is (and should be) allowed to
reactivate copy, since it is a loosening of the
"pre-conditions". (I know, the LSP generally applies to
functions, and not to objects. But I think you get the idea---a
derived class may add functionality, as long as all of the
functionality of the base class still works.)
FWIW, it's not totally inexistant in my derived classes to add a
private copy constructor, to support cloning, even though the
base class forbids copying (by deriving from
Gabi::Util::UncopiableObject---which is probably identical to
boost::noncopyable, but a bit older).
The rest just keeps the compiler from self-generating the
copyable interface...I don't think it was ever meant to try
rescuing people from their own stupidity and I don't see how
it even could.
The problem with trying to make anything idiot proof is that
nature keeps coming up with better idiots. No matter what you
do, it will fail in the end.
--
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