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

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:

[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