"Andy Little" <andy@servocomm.freeserve.co.uk> 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