From: Eric Lemings (lemings_at_[hidden])
Date: 2007-04-03 14:17:29
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Matthias Schabel
> Sent: Tuesday, April 03, 2007 11:28 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [Review] Quantitative Units library
> review begins today,March 26
> 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.
The problem is that everyone will have a different opinion on what is
And as we have seen also, even the SI units are subject to local
conventions which is why I said "possibly the SI units of measurement".
Many countries use the "metre" spelling and many others use "meter"
and one of these names would be an important symbol in a units library.
And if this is supposed to be internationally standardized unit, other
units and systems will be even more problematic.
Conclusion: Don't even worry about incorporating them into the "core"
library. Leave them as extensions -- supplements if you will -- and
you can even distribute them along with the core library if like. The
important thing is the core library will be much more stable and can
be maintained independently.
> > 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?
Usually the names of such convenience headers reflect the directories
of header files that they include. The <boost/type_traits.hpp> header
is a good example and <boost/units.hpp> would be a nice addition. Once
you break down headers into smaller files (next paragraph), identifying
other such headers is trivial.
> > the headers are rather large and should be broken into smaller
> > headers.
> Which ones, in particular?
Any header file that contains more than one public symbol. That's
the general rule for the "fine-grained" inclusion policy. Sounds
like a lot of work I know but there are good reasons for doing so
especially in an MPL-based library where optimized preprocessing is
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk