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

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-04-03 13:28:12

> 1. The scope of the library must neccessarily be limited.  It should
> contain the dimensional analysis framework, all predefined base and
> derived physical dimensions, dimensionless constants, metric prefix
> wrappers, possibly the SI units of measurement, and that's about it.
> All other dimensions, units, and systems of measurement should be
> treated as "localized" extensions that are built on top of this  
> library.

There are varying opinions on this point. We are attempting to  
provide a complete implementation of the SI standard unit system  
along with a "reasonable" subset of other commonly used units or SI  
conversion factors for them. Perhaps you're right - all non-SI units  
should be moved provisionally to the examples until enough users have  
put the library though the wringer and have given input on other  
units/systems that ought to be incorporated in the core library.

> 2. Exponents should be tightly coupled to their respective dimension
> or unit.  Specifying them implicitly in a list as a pair is not  
> tightly
> coupled.
>
>         unit< meter, 1, gram, 2, second, -1 >

They are - the dimension_list that encodes dimension itself is a list  
of fundamental dimension tag/static_rational value pairs.

> Looking at the proposed library, I would like to see at least one
> convenience header file that includes the "core" library.  Also a  
> few of

Sure - any suggestions on naming the all inclusive header?

> the headers are rather large and should be broken into smaller  
> headers.

Which ones, in particular?

> 5. Don't see the need for ordinal class template.  How is it different
> from the MPL integer constant wrappers?  There are also other such
> questionable symbols (e.g. the whole operators.hpp header,
> make_dimension_list).

Ordinal could be replaced with mpl::int_; I'll look at it. We've  
already stated that we'll look at replacing static_* with the  
corresponding MPL classes.

> 6. Code that should ideally be included as part of other Boost  
> libraries
> (e.g. static_rational as part of Boost Math) should be defined within
> the ideal namespace to indicate the intended namespace partitioning  
> even
> if the header currently resides in the proposed library.

I have no problem with doing this.

> 7. The code sometimes confuses dimensions and units.  Example:
>
> boost/units/systems/si/length.hpp:22:typedef
> unit<length_type,SI::system> length;

This definition is in the SI namespace, so, while length is a  
dimension, SI::length is a unit (aka meter).

> Not sure about the benifits and drawbacks of such a design.

Benefits have been discussed in various emails during the review.  
Mainly, it enables a syntax that is succinct, clear, and unambiguous.

> I tried to build the examples on MSVC 8.0 and Mac OS X but couldn't
> because there is only a BoostBuild v2 Jamfile and v2 is troublesome
> to say the least.  A v1 Jamfile would have been extremely helpful.

I've done all development on Mac OSX without problems either using v2  
or XCode without bjam at all. Steven and a number of others have had  
similar success on a number of other compilers including MSVC 7.1/8.0.

Thanks for your comments.

Matthias