[boost] Re: [1.32 Release] Summary of MPL changes

From: David Abrahams (dave_at_[hidden])
Date: 2004-09-04 09:04:40

"Andy Little" <andy_at_[hidden]> writes:

> "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.

They don't even have a similar meaning.  In MPL the template
parameters are tag types that identify a family of related numeric
types (often specializations of the same class template).

> (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?

No, why?

> 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).

Specifically?

> 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? 

I can't imagine what you might have in mind.

> If so they are extremely useful from point of bringing mpl to user.

More questions than answers.

Sorry,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com