-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matthias Schabel Sent: Tuesday, April 03, 2007 11:28 AM To: boost@lists.boost.org 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.