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
> 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
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
Stated differently, were the changes driven by any kind of user demand?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk