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

Subject: Re: [boost] [boost::noncopyable] compiler warnings with the -Weffc++ flags
From: Daniel Frey (d.frey_at_[hidden])
Date: 2009-06-13 12:48:07

Hi Matt,

Sean reported the same underlying problem against the operators  
library as <https://svn.boost.org/trac/boost/ticket/979>. I applied  
the fix as it was transparent for the users and also suggested a  
similar change for noncopyable on the mailing list - but there wasn't  
much interest IIRC.

The problem with the approach you described is IMHO that if you allow  
noncopyable_<T> as an *alternative*, most people will likely ignore  
it. OTOH, a breaking change - turning the classic noncopyable into a  
template - might be too intrusive. Personally, I would not mind it,  
since the compiler will catch all uses of noncopyable without a  
template parameter and the required change is a no-brainer, so +1 for  
the change from my side. Let's see if more people like the idea this  
time :)

Regards, Daniel

On 13.06.2009, at 18:11, Matt Calabrese wrote:

> Perhaps slightly off topic, but I seem to remember a couple of years  
> ago
> Sean Parent pointing out that noncopyable might be better  
> implemented with
> CRTP. Has this been forgotten? I think the rationale was that if you  
> have
> one child which inherits from two or more bases that inherit from the
> current noncopyable, the empty base optimization can't be used since  
> each of
> the noncopyable bases have to have different addresses, so your  
> type's size
> grows with each additional base that inherits from noncopyable. As  
> well, I
> believe that certain compilers were producing spurious warnings if  
> you use
> such multiple inheritance, suggesting to the programmer that  
> noncopyable may
> be better as a virtual base (which it clearly would not). Making a
> noncopyable template, perhaps called noncopyable_ so that the two can
> coexist, that is implemented the same way but whose intended use is  
> to be
> instantiated with the child type fixes these problems by making  
> certain that
> all noncopyable bases in a hierarchy have different types, meaning  
> that EBO
> may be used and there are no duplicate noncopyable bases.
> -- 
> -Matt Calabrese
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost