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