From: David Walthall (walthall_at_[hidden])
Date: 2007-04-03 12:02:58
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<length_tag,2, mass_tag,1, time_tag,-2,
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
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
* 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk