Re: canceling noncopyable feature
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 think that would provide a more intuitive interface.
It still wouldn't be perfect. You could intentionally get
around it by
MyClass::MyClass(const MyClass &toCopy )
: boost::noncopyable( some_trait )
{ }
but at least you would have to work at shooting
yourself.
Yes, and there will be somebody [more radical in their view] who'd come
and complain about that one. Wanna bet?
There is no way to satisfy everybody. Document what the class does and
what the intended use of it is, and let it go. 'boost::noncopyable' is
apparently intended to make a derived class such that the compiler
cannot produce a copy-ctor for it, which, provided the user does not try
to create a copy-ctor him-/herself, will make the derived class
non-copyalble as well.
There are always conditions. Nothing is absolute. Remember "null
references"?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask