Martin, Thanks for your comments.
But this one does not live up to my personal expectations raised by that introduction. This is clear to me, but I am afraid others may take some time to discover that fact the hard way. Maybe the not the library, but just the expectation is wrong. To avoid such misconception, please give your potential users the chance to adjust their expectations beforehand.
This is a good suggestion; as you point out, there is no benefit in having the expectations of potential users set beyond the scope of problems that the library actually addresses. I will add a clarifying section on "Domain of application and restrictions" to the documention as you suggest.
Since the library does not allow for mixed storage of quantities e.g. in vectors, further workarounds will be necessary when dealing linear algebra like BLAS, LAPACK or other advanced numerical libraries.
Perhaps Boost.Any provides a solution to this issue? This code compiles OK : boost::numeric::ublas::vector<boost::any> v(3); v(0) = boost::any(quantity<SI::length>(3.0*meters)); v(1) = boost::any(quantity<SI::mass>(3.0*kilograms)); v(2) = boost::any(quantity<SI::time>(3.0*seconds)); I honestly don't know how frequently the problem of containers of heterogeneous quantities will arise, but I understand that there may be situations where this is the case.
The library provides support for language-independent serialization by the use of Boost.serialization library. No attempt is made to ensure that the units of the deserialized quantities match the ones of the serialized ones.
Clearly, there is a limit to what one can accomplish when converting between a data stream of raw bytes to a class. Furthermore, the overhead involved in storing specific type information on units and quantities could be significant, so that storing a large array of quantities would occupy dramatically more disk space than the corresponding array of value types. This problem is a general one, anyway : I don't know of any Boost libraries that provide type checked serialization.
No attempt is made to provide formatting for quantities in human readable form (beyond debugging output).
At present this is true. However, I believe that extending the formatting options is a reasonable request and will be given serious consideration for future incarnations of the library. This would include IO manipulators and facets to control human language dependent output.
No attempt is made to provide parsing of unit input in human readable form."
This is true at present. Since, as you already are aware, the unit must be specified at compile time, this would provide minimal utility at present. However, we would be delighted to work with you to ensure compatibility and interoperability if you are interested in implementation of a library for handling runtime units. Ultimately, as many if not most participants in Boost are volunteers doing the work on their own time, expecting complete solutions of significant problems like those posed by units to be provided in monolithic form, I believe, will just end up preventing anything at all from being accomplished in the problem domain. Ultimately, the process functions best via collaboration, with multiple individuals contributing their expertise to solve problems within their domain of experience and interest. Regards, Matthias