John Maddock wrote:
I'm mildly against that in Boost.Config: the issue seems to be VC12, ...
No. The suggested addition in
https://github.com/boostorg/type_traits/pull/52/commits/9779157a787620d16330...
is wrong; there's nothing type_traits can do about it because instantiating
the constructor is not an immediate context and not subject to SFINAE.
The problem is in has_trivial_constructor> and is caused by the
following logic in boost/type_traits/has_trivial_constructor.hpp:
#if (defined(__GNUC__) && (__GNUC__ * 100 + __GNUC_MINOR__ >= 409)) ||
defined(BOOST_CLANG) || (defined(__SUNPRO_CC) &&
defined(BOOST_HAS_TRIVIAL_CONSTRUCTOR))
#include
#define BOOST_TT_TRIVIAL_CONSTRUCT_FIX && is_default_constructible<T>::value
#else
which is then used in
template <typename T> struct has_trivial_constructor
#ifdef BOOST_HAS_TRIVIAL_CONSTRUCTOR
: public integral_constant {};
#else
That is, the issue only occurs when (a) the compiler is gcc >= 4.9, clang,
Sun, (b) the compiler has intrinsic support for __has_trivial_constructor,
(c) instantiating the type's default constructor is a hard error.
The latter is the case for pair before the change
in the standard that made its default constructor SFINAE-friendly.
So in practice, this manifests on Travis on gcc 4.9 and clang using
libstdc++ before 5.
