On 3/26/07, John Phillips <phillips@delos.mps.ohio-state.edu> wrote:
The review for the Quantitative Units library, submitted by Matthias Schabel and Steven Watanabe begins today, March 26 and ends April 4.
• What is your evaluation of the design? I am really glad that this version of Boost.Units has limited its scope to purely compile-time. That's not to say that I wouldn't welcome a run-time version (I would!), but I think a narrow scope is essential to getting a units library into Boost. I have tried extending the library to use custom units and it's very easy to do. I do wish that there was no need to specialize base_unit_converter for conversions both ways when the second specialization is simply the reciprocal of the first. Steven posted a solution to this in a separate thread just now and I hope that it will get included in the final version. • What is your evaluation of the implementation? I know Matthias and Steven have put a lot of effort into making sure it's as efficient as possible, both in compile and run time. It looks very high quality. The following actually concerns design, implementation, and docs, so I wasn't sure where to put my comments: Example 16 looks strangely familiar! Glad to see it was interesting enough to make the examples. Concerning nautical miles: see http://en.wikipedia.org/wiki/Nautical_mile and http://www1.bipm.org/en/si/si_brochure/chapter4/table8.html. I'm not sure if this unit makes sense in the nautical namespace. One might ask "Why not boost::aerial?" The only reason I bring this up is because they are used for marine and aerial navigation. There may be other such examples, but I think all of the non_si_units.hpp units could reside in a boost::non_SI namespace with little confusion to the user. These would be all non-SI, but accepted, units (see http://en.wikipedia.org/wiki/Non-SI_units_accepted_for_use_with_SI). I also noticed that the unit knots was not defined in non_si_units.hpp. Is this an oversight? Why are some accepted non-SI units defined and others not? Is there an exhaustive list in the docs mentioning all units and their systems? • What is your evaluation of the documentation? I spent a lot of time using the docs as a user, not a reviewer. So far I don't have any major complaints. If I have time I will go back with a more critical eye and submit all design issues, typos, and grammatical errors in a separate e-mail, but for the most part they were very consistent with other Boost docs, and I found the examples quite helpful. I was able to extend the library with custom types very easily using the documentation provided. • What is your evaluation of the potential usefulness of the library? I think it will be extremely useful for users who want this type of safety with zero space and run-time penalty. I have already used earlier versions of this library in toy programs and prototypes with much success. These include GUIs where the user chooses what unit to provide his input in, and output to a visualization layer. • Did you try to use the library? With what compiler? Did you have any problems? Yes, VS 7.1 and VS 8.0. No problems to report. • How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have been using this library in various stages of its development in prototypes and toy applications. Part of that required delving into the source to figure out compile errors I was having early on, and part of that required extending the library to use custom types. I spent a total of about 4 hours using the review version of the library, but weeks of use with previous versions. • Are you knowledgeable about the problem domain? Not especially. The programs I work on are mostly GIS related, and rarely deal with physics, fluid dynamics, or things of that nature. The applications I deal with get values from databases that store things like radar characteristics, aircraft performance metrics, and terrain and elevation data. None of them use a unified unit system, so the existing legacy code is rife with conversions. I've encountered two bugs so far where meters were being compared to feet, and I'd like to turn bugs like that into compile-time errors. • Do you think the library should be accepted as a Boost library? Yes, certainly. I would, however, like to hear Matthias' and Steven's thoughts on how easy it would be to add a run-time layer on top of their existing work. Thanks for all your hard work. --Michael Fawcett