From: Andy Little (andy_at_[hidden])
Date: 2004-09-03 15:37:42
"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> 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.cpp?view=markup
> 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