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?