"Matt Austern" <austern@gmail.com> wrote
There's actually something even lower level than a dimension library. In essence, what we've got is: - We're generalizing the notion of an arithmetic type T to a type of the form <T,X>, where X is some sort of tag. - For any X1 and X2 and any arithmetic operation 'op', we have rules for whether <T,X1> op <T,X2> is well defined. If it is then the result is tagged as <T,X3>, and we have rules to determine X3 in terms of X1, X2, and op.
I dont understand the tag part. (This must work seamlessly for inbuilt types too.) "for any T1 and T2" ... "rules to determine TR ( the result_type) in terms of T1, T2 and op". ..? I am not sure if this is exactly what you mean but I have tried to raise this on comp.std.c++: http://groups-beta.google.com/group/comp.std.c++/msg/a921d4d5bdb362e2 (note the above code inspired by Doug Gregors code in a boost discussion ) I think something like that would still be required for implementation even when decltype and auto are in place.
All of the knowledge about how to represent dimensional systems (mpl vectors, compile-time fractions, etc.) is higher level than this.
As a detail, I think dimensions is orthogonal, eg mpl::plus<int_<A>,int_<B> >::type mpl::plus<int,int>::type The first is a compiletime operation, whereas the second is misuse of mpl::plus for result_type deduction. dimensional analysis occurs as the first, whereas we are discussing result_type deduction above. I Think ! regards Andy Little