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 14:04:28

On 21/08/2014 01:00 p.m., Peter Dimov wrote:
> 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:
> It only affects triviality:
>
>> 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? :-)

That comment was about a trivial default constructor only. I fail to 
imagine a case where one has a default-constructible noncopyable thingy, 
and whether that constructor is trivial or not matters other than for 
the trait.

In any case, I may have misrepresented my position. I do not know about 
what the common use cases of `noncopyable` are, and I'm not a user 
myself. My point is simply that trivially copyable is an orthogonal 
thing to copyable today, so `noncopyable` should not be concerned with 
it. If it turns out the definition of trivially copyable is wrong and 
it's changed, then `noncopyable` will be benefit from that change 
transparently.

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

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

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

I have some low-level optimizations in mind as well, but I don't dare 
say they are fully conformant yet. I need to investigate more.

>> 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?

Why indeed? I guess it would have been a compiler bug, so it would be 
fair for me to strike the "entirely" from my comment above. In any case, 
the end result was the same, after repeated occurrences of these 
unhelpful error messages I just replaced it with forcing compile time 
error messages where I could.

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