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 :-)
>> > .. 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
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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk