On 1 June 2014 21:40, Peter Dimov wrote:
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. :-)
Anecdata: I often do tag dispatching on traits and overload a function to take either std::true_type or std::false_type, where I know the trait is guaranteed to derive from one or the other (which is true for all the standard type traits, and others that I write). It wouldn't surprise me if other people do that with mpl::true_ and mpl::false_ , relying on traits deriving from exactly those types.
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.
That pervasive dependency and the hundreds of lines that get included are why I immediately replaced all boost type traits with the C++11 equivalents when a couple of projects moved to a C++11 compiler. Would it be possible to define true_ and false_ with a lot less code?