On 3/28/07, Martin Schulz <Martin.Schulz@synopsys.com> wrote:
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.
Wouldn't the run-time library suffer even more restrictions when it came to BLAS, LAPACK, etc? Those functions want a float or double pointer that points to a contiguous array (the functions do not have a stride parameter), as well as an array size. quantity<abstract> will have to be more than a simple value if you want mixed storage and run-time conversions. It requires polymorphism, or carrying around an extra 'unit type' variable. The run-time library does allow things like: vector<quantity<abstract> > quantities; but I really don't see how interfacing with BLAS, et. al. would be possible directly. The compile-time version, on the other hand, DOES interface directly if the vector was full of say quantity<SI::length> since those are simply doubles.
Because the physical dimensions of all quantities are fixed ad compile time, there is no support for code that acts on certain quantities regardless of what these quantities actually represent, i.e. all quantities specified at runtime of the software. This includes GUI frameworks, post processing or visualization tools.
The current version does not preclude use with any of those. Currently I have a GUI that accepts meters, nautical miles, miles, and feet, depending on what the user wants to input his values in. It processes that input with other values gathered from various databases (feet and nautical miles) and then displays the results to a window rendering with OpenGL (so I had to convert the values to OpenGL units).
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.
No attempt is made to provide formatting for quantities in human readable form (beyond debugging output).
No attempt is made to provide parsing of unit input in human readable form."
I look at all of those as huge wins for this submission. The can of worms you open up when trying to solve the I/O issues with units and locales is huge, and IMHO warrants a separate, interoperable submission. --Michael Fawcett