Le 01/06/14 22:40, Peter Dimov a écrit :
We have lots of headers that depend on mpl::bool_ in order to define traits classes as deriving from mpl::true_ or mpl::false_.
I don't think that this dependency is necessary even for MPL interoperability. The normal way of
template<class T> struct trait { BOOST_STATIC_CONSTANT( bool, value = false ); };
should work just as well. I think.
As one example, there's detail/blank.hpp, which starts with
#include "boost/mpl/bool.hpp" #include "boost/type_traits/is_empty.hpp" #include "boost/type_traits/is_pod.hpp" #include "boost/type_traits/is_stateless.hpp"
It doesn't really need these includes.
namespace boost {
struct blank { };
// type traits specializations //
template <> struct is_pod< blank > : mpl::true_ { };
This can be written as
template<class T> struct is_pod;
template<> struct is_pod< blank > { BOOST_STATIC_CONSTANT( bool, value = true ); };
This will need boost/config.hpp
which requires no includes.
The problem is, though, that all type traits do derive from mpl::true_ or mpl::false_, and I'm not sure if rewriting blank.hpp in the above manner is actually correct. Should type trait specializations always derive from mpl::true_ or mpl::false_? Will I break something if I specialize a type trait to not derive from mpl::bool_? Or is a nested ::value enough? Who knows. :-) Currently the type traits derive from true_type or false_type.
is_pod
http://www.boost.org/doc/libs/1_55_0/libs/type_traits/doc/html/boost_typetra...
template <class T>
struct is_pod : public /|true_type http://www.boost.org/doc/libs/1_55_0/libs/type_traits/doc/html/boost_typetra...-or-false_type http://www.boost.org/doc/libs/1_55_0/libs/type_traits/doc/html/boost_typetra...|/ {};
The problem is that integral_constant inherits from mpl::integral_c.
I suggest to change the contents of integral_constant.hpp to something like
template
But really, if a header, whose entire purpose is to define an empty struct, can't get by without including type traits and mpl, we've lost the dependency game before it's even started.
You are right, some refactoring is needed. I propose to move this integral_constant.hpp file to Boost.Core. Best, Vicente