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

From: David Abrahams (dave_at_[hidden])
Date: 2004-02-01 07:39:51

"Andy Little" <andy_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:ur7xfv7yt.fsf_at_boost-consulting.com...
>> "Andy Little" <andy_at_[hidden]> writes:
>>
>> >> These aren't very interesting metafunctions, since they're all
>> >> equivalent to mpl::always<implementation_defined> ;-)
>> >
>> > Oops sorry perhaps read 'undefined',' user defined' not implementation
>> > defined :-)
>>
>> My point was to say that you are proposing we add something to the
>> library,
>
> Whoa ! 

Whoa, what?  Are you not proposing we add something to the library?

> First I decide against using mpl at all. I was accused of being
> 'ad-hoc'. I decide to try it. I find a problem. Next I posted a question on
> users about how to integrate a power function with mpl. NOTE the "Ideally"
> in second line !!! Here is Alexei Gurtovoys reply:

<snip>

Whoa! I saw Aleksey's reply when he posted it.  What's your point?

>> but you haven't shown us anything but a sketch of a few empty
>> metafunctions.  How can anyone comment?
>
> I don't know but that doesnt seem to stop you guys! 

You did end your post with: "Feedback welcome."

> This was not a Proposol
> but a tentative question...what if. 

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"

> The next version of pqs will be
> available soon. The metafunctions are in!. What namespace to put these
> metafunctions in TBD. Meanwhile you may need to use your imagination. It
> should not be too hard to understand their purpose surely?. 

I don't have a problem understanding their purpose.

> Zounds!

Take it easy, dude.

> .. 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.

> 1)  Can there be some operators representing power,root and reciprocal in
> mpl?. Some other math functions might also be useful... e.g to work around
> compile time real calc problems.
> 2)  If 1), what names can mpl connoiseurs provide? I prefer this type of
> thing:
>
> boost::mpl::pow_t<my::my_type,my::my_exp >::type y;
>
> 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".

> , says its a metafunction, has history

What history is there behind "pow_t"?

> and prevents nameclash with runtime. 4 for the price of 1 :-) It was of
> course rejected ... because "One  would consider it a reprehensible
> abomination to use such a convention in mpl. It is simply not
> Done."..etc.

Don't be such a drama queen; what was actually said was a lot more
matter-of-fact.  You did ask for feedback.

> Although no logic followed.

False.  The logic is that we already have a naming convention in MPL.
Are you proposing to change it now?  Non-conformance weakens any
convention.

> Hmm..hm.hm ... I could do:
>
> plus_t<q_length::m,q_length::mm>::type L;
> divides_t<q_length::m,q_time::s>::type  V;

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:-)
>
> 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.

> 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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com