From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-02-06 08:09:39
> >> 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 dimentioned-quantities, 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
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
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
- 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 performance-test the different approaches on several platforms.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk