From: Matthias Schabel (boost_at_[hidden])
Date: 2007-04-03 13:14:10
> This library satisfies all of the requirements I have for a unit
> compile-time dimensional analysis, zero runtime overhead (at least in
> theory), and explicit conversions to other systems (such as meters ->
> inches). I recommend that this library be accepted.
Thanks for the thumbs-up.
> The only complaint I have is that unique values of ordinal<N> have
> to be
> used. It seems like this could cause incompatibility issues if two
Unfortunately, as Steven points out, the only other way to do this is
ugly and convoluted unless some C++ mega-guru comes up with a way of
generating a unique ordinal sequence of integers at compile time. I
think that it will be impossible given the compile/link structure of C
++ compilation, though...
> typedef for a new type, such as molar_energy_type, was something like:
> composite_dimension<energy_type,1, amount_type,-1>::type
> instead of:
> composite_dimension<length_tag,2, mass_tag,1, time_tag,-2,
We're going to be going through some of the lower level code for
defining units/systems with an eye to significantly simplifying it.
I'll think about this at that time...
> My final suggestion is that CODATA constants should be available for
> libraries that do not support typeof. (I expect that this will be
> fairly straightforward since the units are known.)
Right now it's implemented with Boost.Typeof - is there a compiler
out there that is in common use that does not support typeof
emulation at least?
Cheers, and thanks for helping out with the testing.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk