Re: [boost] [boost::noncopyable] compiler warnings with the -Weffc++ flags

Subject: Re: [boost] [boost::noncopyable] compiler warnings with the -Weffc++ flags
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2009-06-19 03:00:24

On Thu, Jun 18, 2009 at 9:01 PM, David Abrahams <dave_at_[hidden]> wrote:

> Ironic, since in Sean's world, all types are copyable :-)
>

Ha, yes, and I even tend to agree. I look at noncopyable as more of a
utility to prevent people from copying either because the operations just
haven't yet been implemented or because there is currently no practical
use-case for it to be called. In a perfect world, every type would be
regular and it would take no time or effort to make them such, but the world
is sadly not perfect.

On Thu, Jun 18, 2009 at 9:50 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> I'm not really sure there's a better name for what it does.  Why should
> a different tag be used?

It's not that important to me and is more subjective than anything else. I
don't see any issue with the name, more that it's reusing a type intended
for a technically different purpose _because_ of that name (a noncopyable
tag type with the same name in ::boost::python for instance would be fine if
not potentially confusing). The use of noncopyable in Boost.Python does not
directly relate to its documented purpose if you read the documentation of
noncopyable. Again, it's really just used because of the name rather than
the type's actual purpose.
If noncopyable were a more complicated type or if its use were vastly
different from its use in class_, I'd see it as an actual problem, but given
that it's just a simple little utility type that doesn't even really depend
on anything, there is no practical reason why it shouldn't be used. I doubt
it even causes any confusion so it's just more of a philosophical issue at
that point and I wouldn't use that alone as a rationale for a change. The
only real issue as I see it is that if noncopyable becomes a template, it is
a little bit less clear as to what exactly should be done for class_ to
reflect the change.
-- 
-Matt Calabrese