type_traits / MPL interoperability
I just ran into a problem caused by the TR1-ization of the type traits library. I had a function defined this way: template <class T> typename is_fundamental<T>::type f(T) { return mpl::bool_< is_fundamental<T>::value >(); } that wouldn't compile. Eventually I discovered that it was because type traits now yield instances of integral_constant<T,N> (is that documented somewhere now?) integral_constant<T,N> is derived from mpl::integral_c<T,N>, but mpl::bool_<N> is not derived from integral_constant<T,N>. I can understand not wanting to introduce that sort of two-way coupling between the libraries, but it also seems like the only way to make everything work smoothly. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com
I just ran into a problem caused by the TR1-ization of the type traits library. I had a function defined this way:
template <class T> typename is_fundamental<T>::type f(T) { return mpl::bool_< is_fundamental<T>::value >(); }
that wouldn't compile. Eventually I discovered that it was because type traits now yield instances of integral_constant<T,N> (is that documented somewhere now?)
Yep.
integral_constant<T,N> is derived from mpl::integral_c<T,N>, but mpl::bool_<N> is not derived from integral_constant<T,N>. I can understand not wanting to introduce that sort of two-way coupling between the libraries, but it also seems like the only way to make everything work smoothly.
integral_constant<bool,b> derives from mpl::bool_<b> for backwards compatibility. Stupid question but why doesn't your function do: template <class T> typename is_fundamental<T>::type f(T) { return is_fundamental<T>::type(); } John.
"John Maddock" <john@johnmaddock.co.uk> writes:
integral_constant<bool,b> derives from mpl::bool_<b> for backwards compatibility.
For still more backward compatibility we ought to have a conversion in the other direction.
Stupid question but why doesn't your function do:
template <class T> typename is_fundamental<T>::type f(T) { return is_fundamental<T>::type(); }
Stupid answer: broken compiler workaround. Anyway, this isn't a big deal. Maybe not even worth acting on. -- Dave Abrahams Boost Consulting www.boost-consulting.com
integral_constant<bool,b> derives from mpl::bool_<b> for backwards compatibility.
For still more backward compatibility we ought to have a conversion in the other direction.
I realised that right after I posted (as usual, post first think later. Doh!) Are there any drawbacks to making the constructors of these types non-trivial?
Stupid question but why doesn't your function do:
template <class T> typename is_fundamental<T>::type f(T) { return is_fundamental<T>::type(); }
Stupid answer: broken compiler workaround.
Anyway, this isn't a big deal. Maybe not even worth acting on.
OK, how about just using "is_fundamental<T>()" directly, no need to access it's ::type member at all really ? John.
"John Maddock" <john@johnmaddock.co.uk> writes:
integral_constant<bool,b> derives from mpl::bool_<b> for backwards compatibility.
For still more backward compatibility we ought to have a conversion in the other direction.
I realised that right after I posted (as usual, post first think later. Doh!)
Are there any drawbacks to making the constructors of these types non-trivial?
Only the usual ones, I guess ;-)
Stupid question but why doesn't your function do:
template <class T> typename is_fundamental<T>::type f(T) { return is_fundamental<T>::type(); }
Stupid answer: broken compiler workaround.
Anyway, this isn't a big deal. Maybe not even worth acting on.
OK, how about just using "is_fundamental<T>()" directly, no need to access it's ::type member at all really ?
It's not an obstacle for me at the moment, so I'm okay -- but it did surprise me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams -
John Maddock