Boost logo

Boost :

Subject: Re: [boost] [core/noncopyable][test/boost::unit_test::singleton] massive test failures
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-08-21 08:26:04

On Thursday 21 August 2014 13:07:03 John Maddock wrote:
> >> There's a problem with noncopyable and boost::unit_test::singleton in
> >> Intel
> >> 13 for Linux in C++11 compatibility mode that's rippling through many
> >
> >> Boost libs. To list a few:
> > This is already being solved:
> Sort of... this fix depends on setting an undocumented and untested
> config macro that was added while I wasn't paying attention.

That was my omission, sorry about that. I'm working on it now and today will
file a pull request addressing your comments to the commit.

> It raises
> a whole host of questions frankly:
> 1) Why on earth is:
> BOOST_CONSTEXPR noncopyable() = default;
> Better than
> noncopyable() {}
> The latter with or without a BOOST_CONSTEXPR?

In the particular case with noncopyable, its constructor should be as little
imposing as possible because the derived class inherits its restrictions. In
the second case the derived class will have non-trivial and non-constexpr
default constructor.

> 2) Are any of the new features of noncopyable tested - if there are
> testable new features that is?

The test for noncopyable doesn't verify that the constructor is constexpr, if
that's what you mean.

> 3) Should the undocumented/tested macro
> BOOST_NO_CXX11_NON_PUBLIC_DEFAULTED_FUNCTIONS exist at all, or should we
> disable the feature altogether (ie set
> BOOST_NO_CXX11_DEFAULTED_FUNCTIONS) for these problem cases/compilers?

Well, the compiler does support public defaulted functions, so the feature is
not totally broken. This is often enough in real world so it's not useless.
I'd prefer to keep the two macros separated (that's why I added a new macro

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