From: Matthias Schabel (boost_at_[hidden])
Date: 2007-03-28 14:54:39
Thanks for your comments.
> But this one does not live up to my personal expectations raised by
> introduction. This is clear to me, but I am afraid others may take
> time to discover that fact the hard way. Maybe the not the library,
> just the expectation is wrong. To avoid such misconception, please
> your potential users the chance to adjust their expectations
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 :
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
> 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
> No attempt is made to provide parsing of unit input in human readable
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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk