Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at