From: Andy Little (andy_at_[hidden])
Date: 2004-02-01 15:23:32
"David Abrahams" <dave_at_[hidden]> wrote
> "Andy Little" <andy_at_[hidden]> writes:
> > "David Abrahams" <dave_at_[hidden]> wrote
> >> "Andy Little" <andy_at_[hidden]> writes:
> > Whoa !
> Whoa, what? Are you not proposing we add something to the library?
What me guvnor? No... It was the other bloke !
> 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 :-)
> > .. 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
> > 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
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
> > result of the runtime operation... maybe that is an important
> > 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
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 :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk