Re: canceling noncopyable feature
mzdude wrote:
On Aug 27, 2: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. 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.
I know macros have a reputation for being *evil* but I think
the following documents the interface and doesn't bring along
any of the derived interface baggage.
#define NON_COPYABLE(x) private: \
##x(##x const & ); \
##x &operator=(##x const ref) const;
class MyClass
{
public:
MyClass();
NON_COPYABLE(MyClass)
};
I don't like the name. I think it should be different. Something like
#define DECLARE_NON_COPYABLE(x) ...
and if you leave out the closing semicolon, you will actually force the
user to write something similar to a class definition statement:
...
DECLARE_NON_COPYABLE(MyClass);
Of course, the problem is that the macro hides the change in the access
modifiers, everything that follows it will be 'private' unless you
change the modifier (which is sort of ugly). Besides, the class is
still copyable for friends and members...
When C++0x is out, we'll have the luxury of prohibiting copying for good
using the 'delete' syntax, even for members and friends...
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask