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 09:46:01

On 21/08/2014 10:08 a.m., Peter Dimov wrote:
> John Maddock wrote:
>> 1) Why on earth is:
>>
>> BOOST_CONSTEXPR noncopyable() = default;
>>
>> Better than
>>
>> noncopyable() {}
>
> I can tell you what's the difference, but not why it's better. :-)
>
> constexpr on the constructor enables noncopyable, and its descendants,
> to be statically initialized. I suppose this makes sense; a mutex, for
> example, is noncopyable but it may be desirable for it to support static
> initialization.
>
> =default makes the constructor trivial. A trivial constructor can be
> omitted. It's not clear to me why a noncopyable class would need to have
> a trivial constructor.

The class inheriting from `noncopyable` is the one that should decide 
whether the constructor should be trivial or not. Defaulting the default 
constructor makes this decision possible.

> Similarly, =default on the destructor instead of {} makes it trivial. A
> trivial destructor may be omitted. It makes approximately zero sense for
> a noncopyable class to have a trivial destructor.

Having a defaulted destructor is redundant, but explicit. I don't see 
why `noncopyable` ever needed to spell out a destructor. But the same 
point as above applies, specially since a literal class requires a 
trivial destructor, so a constexpr default constructor only makes sense 
with a trivial destructor (IIRC it's an error otherwise).

> The funniest part is that =delete on the copy constructor makes the copy
> constructor trivial as well, in C++11. A trivial copy constructor means
> that the class is copyable with memcpy. :-)

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.

> (There is a core defect report against that though, if I'm not mistaken.)

There is, but core wants to keep deleted special members trivial. I 
believe this to be the correct approach, and I don't think it's likely 
to change if anything else because it would be a breaking ABI change. 
This is off-topic anyway.

> In summary, I don't see the new noncopyable as better than the old one
> in any significant way.

I disagree. The new implementation does not interfere with things other 
than copyability.

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