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 = quantity<double,SI::length>::from_value(1.5); 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 <-/-> 1.5*CGS::centimeter*CGS::seconds/CGS::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. Regards, Matthias