Re: [boost] [Review] Quantitative Units library review begins today, March 26

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-03-28 17:30:02

On 3/26/07, John Phillips <phillips_at_[hidden]> 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