
Boost : 
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 20080206 08:09:39
Hello,
> >> boost.units:
> >> pow<3>( length )
> >> is going to have units of volume.
> >
> > Ah yes, forgot that. My gut feeling is that Boost.Math should
> > concentrate on the um... math: provide a nice simple
> > implementation that's reasonably efficient too. And libraries
> > like Boost.Units can overload it for dimentionedquantities, and
> > use the Boost.Math version for the internal calculation.
> > Does this make sense?
> In principle yes, but in practise, I think Boost.Units will need to
> calculate the result type via the * operator, so it might as well
> calculate the result value at the same time. Of course, that doesn't
> mean Boost.Units can't copy the implementation mechanism but then the
> advantage of having "pow" in a single location is lost.
>
About the result type issue, my original think was just a chain of type
deductions that would have looked like this:
positive_power<0, T> returns a int (the scalar 1)
positive_power<1, T> returns a T
positive_power<N, T> returns the type of operator*(T, type of
positive_power<N1>)
power_if_positive<N, T, true> returns the type of positive_power<N>
power_if_positive<N, T, false> returns the type of operator/(double, type of
positive_power<N>)
power<N, T> returns the type of power_if_positive<N>
But I haven't dug yet about the possible implementation of this approach.
The two questions that come to my mind are :
 are all those type deductions even possible with Boost.Typeof? (I know
about the main principle of Boost.Typeof but have never really used it
before)
 is this approach going to return the right type in all cases for
Boost.Units? (that is, for instance, does operator*(length, length) return
an area, does operator*(length, operator*(length, length)) return a volume,
etc...) And what about power<0>? Is there a "scalar" type in Boost.Units?
For now I continue to concentrate on the first general solution we already
have and performancetest the different approaches on several platforms.
Regards
Bruno
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk