[bind10-dev] noncopyable classes

[JINMEI Tatuya / 神明達哉]

At Mon, 14 Feb 2011 10:37:57 +0100,
Jelte Jansen <jelte at isc.org> wrote:

> we have certain classes that we want to be noncopyable, and so far I've seen two
> different ways to do this;
> 
> 1. make it a subclass of boost::noncopyable
> 2. make the copy constructor and the assignment operators private
> 
> The first is slightly shorter, but the second is not that much more work, and it
> has the slight advantage that it at least gets rid of one dependency on boost in
> our headers.
> 
> And of course for the sake of consistency it's better to only use one method
> here, so I'd like to propose we update the coding guidelines to use method 2 for
> this.
> 
> Any thoughts?

I prefer method 2, so I agree, but I also see there can be an argument
for method 1, so I understand it's generally a preference matter.

I prefer method 2 because
 - In general I want to keep minimizing reliance on boost definitions
   in public header files
 - As you say, in this particular case the "in house" version would be
   quite trivial and widely known idiom in C++ (so the disadvantages
   of using an "in house" notation should be marginal)
 - One possible argument against method 2 would be that the intent is
   less obvious.  But IMO making a class non copyable is often an
   important design decision and we should note that explicitly in the
   doxygen documentation (not only about the fact that the class is
   non copyable but also with the reason why we do so).  With the
   documentation this advantage should also be addressed.

Avoiding multiple inheritance could also be a reason for method 2, but
I personally don't think it a strong reason.  In this case common
drawbacks of multiple inheritance (such as the diamond paradox) would
be less likely to happen.  But I don't object to the argument itself,
either.

Defining our own explicit "non copyable" class with multiple
inheritance can also be an option.  I don't have a strong opinion
about this approach, but I'm not so sure if it makes sense to define
more indirection than using the commonly used idiom directly.  Also,
if we reject the use of boost::noncopyable due to the requirement of
multiple inheritance, that argument also applies to this approach.

---
JINMEI, Tatuya