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 12:00:24

Agustín K-ballo Bergé wrote:
> > And, while I can grudgingly accept the argument that the class deriving 
> > from noncopyable needs to decide whether to be trivially constructible 
> > or not, in this case, it is not that class that makes the decision. All 
> > classes deriving from noncopyable weren't trivially copyable with the 
> > old implementation and are now trivially copyable.
>
> True, it is a breaking change for classes relying on an implementation 
> provided default constructor.

Huh. I must be missing something. The default constructor does not affect 
trivial-copyability:

A trivially copyable class is a class that:
— has no non-trivial copy constructors (12.8),
— has no non-trivial move constructors (12.8),
— has no non-trivial copy assignment operators (13.5.3, 12.8),
— has no non-trivial move assignment operators (13.5.3, 12.8), and
— has a trivial destructor (12.4).

It only affects triviality:

A trivial class is a class that has a trivial default constructor (12.1) and 
is trivially copyable.

> I'm having a hard time deciding where this matters...

Perhaps not. After all, I was arguing that close to zero current uses of 
noncopyable are trivial. But you and Andrey were arguing the opposite, that 
making 'noncopyable' trivial is a feature. So... does it matter or does it 
not? :-)

> As I see it, since trivially copyable does not imply copyable, it is 
> irrelevant for `noncopyable`. Even when it sounds funny.

It would be irrelevant in a world in which all code carefully guards its 
is_trivially_copyable checks with is_copy_constructible. This is not that 
world.

But even if we constrain ourselves to abstract theory... what meaning do you 
give to TriviallyCopyable & ~Copyable? What does it imply?

> Whether this matters, I don't know. I wouldn't use `noncopyable` in C++11 
> code, and I stopped using it in C++03 code a long time ago because it 
> would result in "error: undefined reference for blablabla" with absolutely 
> no context on whether the copy attempt happens (not entirely 
> `noncopyable`'s fault, but enough to make it useless for me).

Interesting. Why would the copy being private not result in a compile-time 
error?