"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
[snip]
Whoa !
Whoa, what? Are you not proposing we add something to the library?
What me guvnor? No... It was the other bloke ! [snip]
What kinds of answers were you expecting? The only technical content in your post was the names of three metafunctions. My feedback was, basically, "you should follow MPL naming conventions, and if you want more feedback you'll need to show more details".
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. 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. 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 :-)
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? [snip]
the _t suffix says it returns a type
Another creative non-conformance with MPL naming conventions. All metafunctions return types, and we don't want to uglify them all with "_t".
I like it...ok forget it :-)
, says its a metafunction, has history
What history is there behind "pow_t"?
wchar_t, etc ..ok ... forget it :-) [more on _t suffix]
Apparently another conflict with MPL naming.
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. 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.
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 :-)
meanwhile apologies for trespassing in your namespace
If you want to apologize, it should be for asking for feedback and then wigging out and mischaracterizing the responses when they weren't what you expected.
Apologies for the 'attitude'... I have been working 3 days straight on mplising my lib... and I'm smokin' :-) Apologies for my apology... and that one... Thanks for the feedback :-) regards Andy Little