Here is my review of the proposed Boost.Units library. A major shortcoming in C++ for scientific applications is that all quantities are represented as unitless quantities, and it is up to the programmer to ensure unit consistency and correctness. For me, compile-time dimensional-analysis checking is essential to writing scientific applications. Compile-time checking of dimensions helps eliminate bugs. As importantly, it makes for self-documenting code. Finally, when dealing with quantities in different unit systems, it prevents conversion mistakes and inconsistencies. 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. * What is your evaluation of the design? 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 different libraries use Boost.Units and define the units in an incompatible way. However, this could be mostly eliminated by the inclusion of a large set of predefined systems. One feature of this library that I definitely appreciate is the ability to add additional (composite) dimensions. For example adding a molar_energy type can be accomplished in just a few lines of code using composite_dimension. As a convenience, I would like to see the process for adding additional dimensions simplified. It would be nice if the 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 I find the syntax: quantity<SI::length> x = 2.0 * SI::meters; very intuitive. It succinctly expresses the concept that x is a concrete quantity and clearly documents the value that x has. 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.) * What is your evaluation of the implementation? I did not look into the implementation deeply enough to have an opinion about it. However, the compile times of the examples were reasonable enough for me to conclude that it will be usable in the software project on which I work. * What is your evaluation of the documentation? The documentation through the end of the Examples is very thorough and very useful. It provides information and code to illustrate most of the features of the library. In addition, the quick-start provides an introduction that should serve to most people well. As some other people have pointed out, there are some broken links. Finally, the documentation for the internals of the library are rather weak. E.g. boost_units/Utilities.html * What is your evaluation of the potential usefulness of the library? This library is extremely useful for anyone who deals with values that have associated units. As I mentioned before, a major short-coming of C++ (and all other programming languages that I know of) is that values are represented as unitless quantities, and it is the responsibility of the programmer to ensure that all units are consistent. This library removes that burden from the programmer and places it on the compiler. * Did you try to use the library? With what compiler? Did you have any problems? I have experimented with the library and converted a few small applications that used Andy Little's old PQS library. I have tested it under MSVC 7.1 and gcc 3.4.4 (under cygwin). Other than an issue with the __builtin_signbit (which I consider a bug in gcc since it is declared but never defined), all of the examples compiled and worked correctly. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read the documentation and went through the examples. I also wrote a few small programs to explore this library. I then modified some small existing programs to use this library. * Are you knowledgeable about the problem domain? I believe that I am knowledgeable about the program domain. I received a Ph.D. in Chemistry and now work as a scientific programmer. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, I believe that it should be accepted. Thank you, David
AMDG David Walthall <walthall <at> stanfordalumni.org> writes:
Here is my review of the proposed Boost.Units library.
<snip>
* What is your evaluation of the design?
The only complaint I have is that unique values of ordinal<N> have to be used.
<snip>
Nod. The only way to prevent collisions is to use more bits and either guids or compile time strings storing the fully qualified name.
<snip>
It would be nice if the 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
The existing composite_dimension<> is more efficient. If we made such a template it should work for quantities and units, too. composite<SI::energy, 1, SI::amount, -1>::type template<class T0 = dimensionless_type, int E0 = 0, class T1 = dimensionless_type, int E1 = 0, class T2 = dimensionless_type, int E2 = 0, ...
struct composite { typedef typename static_power<T0, static_rational<E0> >::type t0; typedef typename static_power<T1, static_rational<E1> >::type t1; typedef typename static_power<T2, static_rational<E2> >::type t2; ... typedef t0 type0; typedef typename static_multiply<type0, t1>::type type1; typedef typename static_multiply<type1, t2>::type type2; ... typedef typeN type; };
<snip>
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.)
Boost.Typeof is in 1.34 and we have support for emulation.
<snip>
Thank you for your review. In Christ, Steven Watanabe
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
participants (3)
-
David Walthall -
Matthias Schabel -
Steven Watanabe