Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-01-13 00:20:43

I've been making incremental improvements (I like to think, anyway)
in the mcs::units dimensional analysis and unit library. The most
recent version (v0.5.4, in the boost vault, just uploaded) includes
wrappers for all <cmath> functions for which operations on quantities
make sense, provides Boost.Serialization support for units and
quantities, and a significantly expanded and more flexible system for
unit conversion. I have also tightened up requirements on
construction to improve safety in unit computations by making strict
unit construction the default. In the hopes of getting it review-
ready and addressing potential issues before the formal review, I'm
hoping to get some concrete feedback from anyone who has downloaded
and used the library (especially the v0.5.x branch).

To get things started, here are a few questions I have :

1) At the moment, the library enforces strict construction; that is,
quantities must be fully defined at construction :

quantity<double,SI::length> q1(1.5*SI::meters);

is acceptable, but

quantity<double,SI::length> q2(1.5);

is not. Basically, construction of quantities (other than copy
construction) is restricted to products/divisors of scalars and
units, scalars and quantities, and/or units and quantities. This
entails some redundancy, but also avoids errors in generic code where
the unit system may change. In addition, I think it makes the intent
of the code clearer. Direct construction from a value_type is
supported, but through a static member function:

quantity<double,SI::length> q3 =

Obviously, in my opinion, this sort of stuff should be restricted to
libraries where it is necessary and shouldn't be ubiquitous in user
code. I know that there is a camp in favor of implicit unit
conversions (which can be supported in the library through a #define,
though I think this causes more problems than it is worth), and I
have some further thoughts on this below, but I'd like input from the
non-implicit crowd as to whether this is a reasonable approach.

2) I'm not currently satisfied with the I/O aspects, particularly the
lack of a mechanism for internationalization. I'd love to hear any
design/implementation suggestions, especially from anyone familiar
with facets/locales, on how to most gracefully accomplish this...

3) At the moment, it is possible to have completely generic rules for
explicit conversion of quantities between systems by specialization
of the conversion_helper class. The default implementation also
allows simpler conversion implementations by defining the
convert_base_unit template classes for each fundamental dimension
(length, time, etc...) between the two systems to be
interconvertible. I think it may be possible to implement a system
that allows for fine granularity in implicit unit conversion; for
example, SI::second and CGS::second are degenerate units, so they
could be implicitly converted to one another with no computation.
Thus, implicit conversion would be allowed in this case :

1.5*SI::seconds/SI::kelvin <-> 1.5*CGS::seconds/CGS::kelvin

since these are identical quantities, but not in this one :

1.5*SI::meter*SI::seconds/SI::kelvin <-/->

Is this of sufficient interest to invest the effort?

4) Any comments on implementation from those brave enough to look at
the guts of the library would be especially welcome.



Boost list run by bdawes at, gregod at, cpdaniel at, john at