Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2003-12-02 08:31:47


> > A tight coupling of the core libraries should always happen.
> > Since boost::mpl is designed as a core library, we can
> > conclude that type traits can (and should) reuse it
> > and vice versa.
>
> I think this is the point. Most Boost libraries are designed for
> end users, but MPL is most useful to library writers. So why
> shouldn't other Boost libraries use it? In fact, I think it should
> be preferred, if for no other reason than for the portability hacks
> that have already been written for it.

A fair point, however the question is about end users specialising type
traits templates - at present the documented requirement is simply:

template<>
struct has_trivial_destructor<myclass>
{
static const bool value = true;
};

And all mpl dependencies are "implementation details" and not a public part
of the interface. Besides if you look into the gory details (in
type_traits/detail/bool_traits_def.hpp) it is not as simple as "derive from
mpl::whatever", instead there are lots of obfuscating macros, and nasty
workarounds.

On the other hand the TR1 submission has all Unary Type Traits convertible
to std::tr1::integral_constant<> (in effect this is an mpl replacement, but
has uses beyond the obvious mpl-style meta-programming as well). So if we
are serious about tracking the emerging std then we should really introduce
the integral_constant template class and it's typedefs true_type and
false_type, the tricky part is doing this in an mpl-compatible way, because
we obviously don't want to break mpl interoperability.

I think we're too close to release to do anything major here right now, but
as a first step, how about:

template <class T, T val>
struct integral_constant
{
   typedef T value_type;
   typedef integral_constant<T, val> type;
   BOOST_STATIC_CONSTANT(value_type, value = val);
};

BOOST_TT_AUX_BOOL_TRAIT_SPEC2(integral_constant, bool, true, true);
BOOST_TT_AUX_BOOL_TRAIT_SPEC2(integral_constant, bool, false, false);

typedef integral_constant<true> true_type;
typedef integral_constant<false> false_type;

Users can then derive from these to implement their own specialisations.

Footnote: ideally I would like to change bool_traits_def so that all traits
inherit from integral_constant, but I'm not sute if that would break
something or not - Aleksey?

John.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk