Boost logo

Boost :

Subject: Re: [boost] Pervasive dependency upon mpl::bool_
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-02 18:04:22

Le 02/06/14 17:39, Peter Dimov a écrit :
> Vicente J. Botet Escriba wrote:
>> template <> struct is_pod< blank > : true_type {};
> This still breaks dispatch on mpl::true_/mpl::false_. The use case is:
> void f( mpl::true_ );
> void f( mpl::false_ );
> struct X;
> int main()
> {
> f( boost::is_something<X>() );
> }
This is not documented, so the user or the boost library is using an
undocumented feature and must be changed.
> This is existing code, both inside and outside Boost.
I hope that we don't mind breaking code that is using undocumented features.
> Rob Stewart wrote:
>> Put a few pieces into core and change MPL to use or derive from them.
>> For example, mpl:: true_type can derive from a new boost::true_type
>> (which could be an alias for std:: true_type).
+1 for using the existing std when available.
> This still breaks the above use case, as boost::is_something will
> derive from boost::true_type, but not from mpl::true_.
No from my perspective.
> We could add converting constructors to mpl::bool_ taking core::bool_,
> which will fix the above, but may break other, more convoluted uses.
> The 'proper' way to handle that (and the problem with type traits
> using MPL is not limited to mpl::bool_) is to extract the actual type
> traits into core type traits, which do not derive from anything, do
> not include MPL lambda support, and whose implementation does not
> include a non-core library (which is an issue only for
> type_with_alignment and common_type). Then, the current type traits
> would be rewritten as
> template<class T> struct is_something: integral_constant<bool,
> core_type_traits::is_something<T>::value> {};
> and can still include the MPL scaffolding for people who like that
> sort of thing.
> blank.hpp will then specialize the core type trait and the ordinary
> type trait will still pick up the specialization.
IIUC you are proposing to split the type_traits into two levels, those
that don't depend on MPL and those that depend on MPL.
I would like to break the dependency from type_traits and MPL if
possible. And you proposal seems a good transition, but a little bit

Putting MPL and Type Traits on the same module would reduce the
dependencies also.

> That's a real project though. Not just moving a few headers around. :-)
> But it's tractable. The good thing is that the core type traits do not
> have to be written all at once. We can migrate them one by one, at a
> leisurely pace.
Yes the best it to see case by case. Could you show a concerte/real
example so that we are fixed on the proposed approach.


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