Boost logo

Boost :

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

> 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

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at