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
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
> 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
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,
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
> (e.g. static_rational as part of Boost Math) should be defined within
> the ideal namespace to indicate the intended namespace partitioning
> 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:
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk