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
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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk