$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: [boost] Pervasive dependency upon mpl::bool_
From: Peter Dimov (lists_at_[hidden])
Date: 2014-06-01 16:40:19
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 );
};
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. :-)
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.