[boost] Re: mpl functions, pow_, root_, reciprocal

From: David Abrahams (dave_at_[hidden])
Date: 2004-02-01 17:02:46

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

> Ok... boost::mpl::pow, boost::mpl::root, boost::mpl::reciprocal.
>
> Feedback welcome :-)
>
> [snip]
>
>> > .. I
>> > shall write some examples! may lose some accuracy on reciprocal<int_>
>> > !...unless reciprocal< int_>-->rational ... Hmm... found a boost mpl
>> > rational_c :-) ...but no docs :-(
>>
>> Patches welcome.
>
> OK I have started on boost::mpl::rational_c.
> I have derived from that into boost::mpl::integral_rational_c.

I can't imagine what that would mean or why that would be needed.  A
rational number is by definition both:

     a. Not integral
     b. A ratio of integers.

> In implementing that I need some promotion...so may try Fernando Cacciolas
> converter. OTOH Alexey Gurtovoys types_promotion_traits if all needs to be
> mpl. 

I think you want Joel de Guzman's technology.  You might search the
message archives for his postings about it.

> Other promotion metafunction implementations welcome. I seem to
> remember one candidate for the library but dont know where to find it. I
> would be happy to use that if possible.
>
>>From there I go to int_rational, long_rational etc
> I prefer   int_rat but.... ok forget it :-)

Overkill, IMO, but it's your party.

> Finally can use that to implement  simple pow,root reciprocal etc.
> Should I do  reciprocal<integral_c> --> integral_rational_c or is that a
> user thing?

Sorry, I don't understand the question.

>> > Seriously though.. Perhaps that may be better because I am not
>> > using the operators to represent a compile-time operation, but
>> > the type returned as a result of the runtime operation... maybe
>> > that is an important distinction?  And it would solve the
>> > problem...for me anyways:-)
>
> I stand by the above. There are two distinct types of operations.
> Some are designed to return a compile time value. Some are designed to
> return a type. 

MPL metafunctions only deal in types (which may be wrappers for
numbers).  That simplifies everything a lot.

> I keep 'bumping into' this issue and I dont like it ! I suspect it
> occurs only when you start to specialise the operators for UDTs. It
> gets worse, I think Phil Richards uses plus where I would use
> multiplies. One good reason to pull the user level stuff out of the
> mpl namespace to prevent confusion.

Also incomprehensible to me.

>> > Alternatively reserve mpl namespace for 'operators'.
>> > boost::mpl::math   ?
>> >
>> > Whatever you guys decide...
>>
>> I think the MPL conventions are fine as-is, and probably should be
>> followed.
>
> Are there some written guidelines on these conventions or am I just meant to
> 'know' them? hmm..I seem to remember asking this before :-)

Just look back a little bit in the thread to Daniel Wallin's posting
and I think you'll find the answer you seek.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com