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

Subject: Re: [boost] [core/noncopyable][test/boost::unit_test::singleton]massivetest failures
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-08-21 11:58:38

On Thursday 21 August 2014 18:03:02 Peter Dimov wrote:
> 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?

One may rely on the system reclaiming the resources at program termination. I 
know, it sounds ugly, but sometimes you have to do ugly things. Anyway, it's 
not really relevant.

> 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.

The object could perform lazy initialization on its first use. For instance, 
if it's a global logger it could open a file descriptor on the first record 
and prohibit copying to be able to finalize the file correctly (e.g. write a 
footer, perform rotation, whatever).

Anyway, let's not argue about theoretical examples. I believe there are 
different circumstances in the real world and in some cases such design may be 
reasonable. I'm also sure that the real life is able to surprise me in 
unexpected ways, so I try to avoid assumptions.

My point was that noncopyable should not impose any constraints on the user's 
class beyond the ones needed. The fact that it did before C++11 is not an 
advantage but the necessary evil people had to put up with. I don't see why we 
should keep it when we no longer have to.

> 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.

Sure, but following that logic noncopyable shouldn't have existed in the first 
place. It's not that difficult to declare a few functions private/deleted, 
after all. But still it exists and as such it has to do its job well.

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

Well, there was this ticket:

https://svn.boost.org/trac/boost/ticket/6578

I don't remember any discussions on the ML though.