"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote
The arithmetic, comparison and bitwise metafunctions are `polymorphic`, and can operate on a variety of numeric types, including rational, fixed-point and complex numbers. The metafunctions allow `mixed
arithmetic`,
meaning that you can perform an operation on the arguments of different types, and the result will yeild the largest/most general of the arguments types. The infrastructure is provided to allow easy plugging of user-defined numeric types which can be made freely intermixable with predefined library types. See
http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/mpl/test/numeric_ops....
for an illustrative example.
Do numeric_cast template parameters have same order as boost::numeric_cast. It looks like not. (I'm afraid I dont understand mpl enough to really tell) "boost/numeric/cast.hpp" namespace boost{ template <typename Target, typename Source> some_type numeric_cast ( Source S); } //.......... namespace boost { namespace mpl { template<> struct numeric_cast< integral_c_tag,complex_tag > { template< typename N > struct apply : complex< N, integral_c< typename N::value_type, 0 > > { }; }; }} If so ... Is this not a lurking bug waiting to happen? Note however that run_time numeric_cast Source parameter would not be deducible if changed, I think. Other similar inconsistency is (I think) is_convertible). This apart the changes look to me very agreeable with my limited knowledge.I did try mpl once but I think I hit the oddities referred to above. I guess the tagged integral_c types are intended for type safety in arithmetic? If so they are extremely useful from point of bringing mpl to user. regards Andy Little