Boost logo

Boost :

Subject: Re: [boost] [type_traits] Big changes in develop
From: Peter Dimov (lists_at_[hidden])
Date: 2015-05-29 16:18:52

John Maddock wrote:
> > Incidentally, why is our decay<> not the same as std::decay? Should it
> > be changed to conform?
> Yes, I fixed that yesterday, see
> and
> Does that render remove_cv_ref more or less redundant?

remove_cv_ref is not quite the same thing as decay. If you want a
hypothetical common_type that respects references, you'd still need
remove_cv_ref (to compute int const volatile (&) [] from int const (&) []
and int volatile (&) [] for instance.)

That said, remove_cv_ref is no longer used by the common_type

> Also noticed in your code, how easy is it to extend to other built in
> arithmetic types?

Very. I'll add char16_t, char32_t and __int128 support. And __float128 if
you add a Config macro for it. :-)

> And while you're on a roll.... can you see how to fix
> common_type should have
> member ::type only when such a common type exists.

On C++11 or on C++03?

On C++11, it's as easy as

template<class...> struct common_type

template<class T> struct common_type: decay<T>

template<class T1, class T2, class... T,
    class R = decltype(declval<bool>()? declval<T1>(): declval<T2>())>

struct common_type<T1, T2, T...>: common_type<typename decay<R>::type, T...>

On C++03... I don't know, is there a point? It needs expression SFINAE and
default template parameters for function templates and will probably not
compile on most non-C++11 compilers anyway. Might be useful in principle on
clang/gcc in C++03 mode, but is this an important target?

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