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 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 positive_power<N-1>) 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 performance-test the different approaches on several platforms. Regards Bruno