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

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

Agustín K-ballo Bergé wrote:
> My point is simply that trivially copyable is an orthogonal thing to 
> copyable today, so `noncopyable` should not be concerned with it.

That view seems academic.

As a practical matter, noncopyable should very much be concerned with 
trivial copyability. If classes derived from noncopyable have to not be 
trivially copyable, then noncopyable should be defined in a way that would 
make them not trivially copyable.

Stated differently, the meaning of "X: private noncopyable" is not tied to 
the language definition of 'copyable' circa 2011. The 'copyable' term in 
'noncopyable' is not the same as the 'copyable' term in C++11.

Stated as yet differently, if the typical user who says "X: private 
noncopyable" wants to imply by that that X is not trivially copyable, then 
noncopyable ought to be defined in a way that makes X not trivially 
copyable.

> I can't really argue about the potential for misuse of the language.

This is not misuse. It is a correct literal interpretation of the standard. 
If a class is trivially copyable, I can copy it with memcpy and get a copy. 
That's what trivially copyable means.

We can be literal and we can be pragmatic, but switching from one to the 
other is not a consistent position.

> > But even if we constrain ourselves to abstract theory... what meaning do 
> > you give to TriviallyCopyable & ~Copyable? What does it imply?
>
> Strictly speaking it implies TriviallyDestructible, which matters for 
> example if you decide to have a specialization for a wrapper class for 
> TriviallyCopyable types and let all special member functions be
implicit. In that case for `noncopyable` you get a trivially destructible 
wrapper, while any attempt to copy or move it results in a compilation 
error.

That's not what I had in mind when I asked. I'm asking what it means - 
logically - for a type to be trivially copyable but not copy constructible; 
not what follows from the language definition, because I know that, but what 
are the intended properties of the class, or in other words, why would you 
design one.

Not being copy constructible means that the class should not be copied.

Being trivially copyable means that the class bytes can be copied with 
memcpy and the language guarantees that the result is a proper copy of the 
object.

What is the intersection of these two? Who needs to design such a thing?

> > Interesting. Why would the copy being private not result in a 
> > compile-time error?
>
> Why indeed? I guess it would have been a compiler bug, ...

The only case that comes to mind is when you copy the class inside its own 
member function. Which is, I suppose, a legitimate example in which a 
deleted copy is better than a private undefined one.