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

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
"reasonable".

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
paramount.

Eric.