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: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-08-21 13:12:46

2014-08-21 20:18 GMT+04:00 Peter Dimov <lists_at_[hidden]>:

> Antony Polukhin wrote:
>
>  * deleted functions produce much more readable error reports
>>
>
> I wonder. Can you please give an example of these improved errors? I don't
> see much difference on a simple example w/ MSVC 2013.

Without `=deleted`:

noncopyable_compile_fail.cpp:32:34: note: synthesized method
‘{anonymous}::DontTreadOnMe::DontTreadOnMe(const
{anonymous}::DontTreadOnMe&)’ first required here
     DontTreadOnMe object2(object1);
                                  ^
In file included from ../../../boost/noncopyable.hpp:15:0,
                 from noncopyable_compile_fail.cpp:13:
../../../boost/core/noncopyable.hpp: In member function
‘{anonymous}::DontTreadOnMe& {anonymous}::DontTreadOnMe::operator=(const
{anonymous}::DontTreadOnMe&)’:
../../../boost/core/noncopyable.hpp:39:20: error:
‘boost::noncopyable_::noncopyable&
boost::noncopyable_::noncopyable::operator=(const
boost::noncopyable_::noncopyable&)’ is private
       noncopyable& operator=( const noncopyable& );

With `=deleted`:

noncopyable_compile_fail.cpp:32:34: error: use of deleted function
‘{anonymous}::DontTreadOnMe::DontTreadOnMe(const
{anonymous}::DontTreadOnMe&)’
     DontTreadOnMe object2(object1);
                                  ^
noncopyable_compile_fail.cpp:21:11: note:
‘{anonymous}::DontTreadOnMe::DontTreadOnMe(const
{anonymous}::DontTreadOnMe&)’ is implicitly deleted because the default
definition would be ill-formed:
     class DontTreadOnMe : private boost::noncopyable

With GCC use of deleted function reported as an error right at the first
line, while without `=deleted` more text must be looked through.

 * defaulted functions are noexcept
>>
>
> This is a good point. Yes, we could add 'noexcept', but if we're making
> changes, why not =default instead. (Because ugly #ifdefs and compiler bugs,
> but, well.)
>

Because as a benefit we get better results for `is_trivial` and
`is_trivially_constructible` traits. Hard choice between
functionality+performance and ugliness...

-- 
Best regards,
Antony Polukhin