
Boost : 
From: Andy Little (andy_at_[hidden])
Date: 20050202 05:10:08
"Matt Austern" <austern_at_[hidden]> 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://groupsbeta.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, compiletime 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk