Re: [boost] mcs::units informal review request

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-11 14:57:40

Matthias Schabel wrote:

> 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);

On the one hand it is useful to know what unit the value is in and to
enforce such knowledge be explicitly stated in the code.  On the other
hand, since this library has no knowledge of units with conversion
factors other than 1 in any given system...specifying the system in the
template parameter is probably enough to say what is needed; the second
use of the unit then could be considered redundant.  I would leave the
requirement since it necessitates that the developer know what unit they
are working with in case they don't know the system and can't be
bothered to look.

> 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...

I don't think the unit library should do I/O.  I think it is one area
that would be better served as completely left out and let the user
devise the method best suited for their I/O requirements, including
i18n.  Surely the developer knows what dimensions they need to be able
to display and can do something as simple as overriding >><< for that
purpose.

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

Since this library is heavily based on MPL it should use MPL constructs.
 Multiplying dimensions for example should be done with mpl::times<>
instead of creating a new operator (multiply<>) for that purpose.  It
would also be good if the concepts were documented with concepts (the
boost::concepts library) and enforced in algorithms.  There is also a
lack of meta functions to identify units and quantities as types (only
dimensions have this functionality) for use in such things as enable_if
and other meta programming utilities.

I also disagree with the assessment that runtime unit conversions are
unnecessary.  It is my contention that the more common use for a unit
library is to do conversions at runtime with minimal cost in an easy and
efficient (from programmer perspective) way.  Compile time dimension
enforcement is a very useful tool but compile time unit enforcement
without runtime conversion and unit selection is not.  The target
audience for this library, as specified, seem too small to warrant boost
inclusion.

That's my take.