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: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2014-08-21 11:37:47

On 21/08/2014 11:54 a.m., Peter Dimov wrote:
> Agustín K-ballo Bergé wrote:
>> This is not so funny once you accept that `TriviallyCopyable` does not
>> imply `Copyable`. The apparent contradiction that `noncopyable` is
>> `TriviallyCopyable` is not such, according to the language rules.
>
> The fact that a class can be trivially copyable but not copyable is
> precisely what's funny. If you don't 'accept' that, there's nothing left
> to laugh at.

I guess we are saying the same thing.

> 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. I'm having a hard time deciding where this 
matters outside of `is_trivially_default_constructible`. The only case I 
could think of is full initialization of a const object, but it fails in 
those cases now as it was failing before (hopefully this will change one 
day).

>> This is off-topic anyway.
>
> It isn't. We're discussing whether noncopyable is or should be trivially
> copyable, and the decision on that defect report determines whether the
> current implementation is.

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

> Incidentally, the compilers I tried give 0 for is_trivial and
> is_trivially_copyable. They don't seem enlightened.

Only libc++ implements `is_trivially_copyable` (msvc pretends to but 
does a bad bad thing). See 
http://melpon.org/wandbox/permlink/BXhRw5DN8RhnNPw6 for a working example.

>> I disagree. The new implementation does not interfere with things
>> other than copyability.
>
> "Does not interfere" is not the same as "is better than".

I see "does not interfere" as "better than", because it means I don't 
have to go and implement my own version that does only what it's 
supposed to do.

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

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com