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
> system:
> 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,
> amount_tag,-1>::type
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.
Matthias