Re: [boost] [core/noncopyable][test/boost::unit_test::singleton]massivetest failures

Subject: Re: [boost] [core/noncopyable][test/boost::unit_test::singleton]massivetest failures
From: Peter Dimov (lists_at_[hidden])
Date: 2014-08-21 11:03:02

Andrey Semashev wrote:
> For example, an object that is supposed to be initialized by a method 
> call.
> The initialization is not done in the constructor because the object is 
> supposed to be declared in the namespace scope and not pose thread safety 
> issues. A global mutex, for instance.

And, I suppose, there is a corresponding method call to destroy it?

While I can grant you this example, it doesn't seem particularly convincing. 
There are so many things you should remember not to do with the class, 
accidental copies are not a primary concern.

> Another example, a global placeholder used as an anchor for DSL 
> expressions or something like that. Think of something similar to 
> std::cout.

There's no reason to make that noncopyable, unless of course we contort the 
example further and posit that we have several such placeholders of the same 
type that are to be distinguished by address. There do exist real-world 
examples of such 'tokens' - you can give the address of the object to a 
kernel synchronization primitive, say - but again, you have to be very 
careful to only have static variables of that class.

Anyway, let's suppose that those things do exist. What percentage of 
noncopyable uses will be of this kind? More than 0.1%? It's not like you 
can't make your class noncopyable of just the right type without using the 
base class.

Stated differently, were the changes driven by any kind of user demand?