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

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-01-22 14:18:06

Michael Fawcett wrote:
> On 1/22/07, Noah Roberts <roberts.noah_at_[hidden]> wrote:
>> You have a great library, something that might be a great backbone for a
>> runtime units system and provide an extra level of safety, but I think
>> the primary use to most people of a unit library is going to be runtime
>> units you either need to support this directly or better document the
>> methods to use your library for such purposes.  99.99% of the time users
>> are going to stick with a single system, usually the SI system, as their
>> static set of units and will need to do a lot of conversions into and
>> out of these base units.  I understand your desire to keep your library
>> simple and to a single task and goal, but I just don't see much need out
>> there for a library that does static unit conversions but has no concept
>> of runtime units.
> 
> I think the majority of people who participated in Andy Little's
> review and those who have responded to this thread disagree.  We (I
> include myself, and hopefully have interpreted others' responses
> correctly) envision this being mostly a compile-time problem, with a
> much smaller use-case for run-time support.
> 
> The purpose being to catch at compile-time errors that would have
> before gone unnoticed, such as:
> 
> // returns feet!
> double get_altitude_from_sensor();
> 
> // assumes meters!
> bool should_deploy_chute(double altitude);
> 
> // Somewhere in another module
> while (true)
> {
>    double altitude = get_altitude_from_sensor();
>    if (should_deploy_chute(altitude))
>       break;
> }
> 
> deploy_chute();
> 
> Sound familiar?   ;)

Yes, it does sound familiar but it is just a common way of writing bad 
code.  In any given project your base unit should be the same for any 
given function.  Anything that accepts a length should accept either 
feet or meters, and a mix of both in your project is a Really Bad Thing. 
  Really the only thing this static unit library provides is a way to 
enforce a policy of base units.  This is a good thing but is rather 
incomplete without a way to interact with the user, who will want 
his/her display and entry in different unit formats.

A value class that did automatic conversions to/from the base unit is, 
in my opinion, more useful.  This class just always converts to an si 
unit appropriate for a given dimension (and static dimensional analysis 
is definitely useful) provides the same safety as static unit 
conversion/enforcement provided here.  Another value type that has no 
unit but has conversion from a value with a unit provides an interface 
for functions to use in calculations so that conversion is not done in 
several places through calculations.  If I where to use this currently 
proposed library that is where it's value type would reside.

Now, if the library is extensible to handle this, in my experience, 
broader need then all that needs to be done is to more thoroughly 
document how one would go about it.  Like I said before, it would be 
nice to use this library as a backbone for a runtime unit system, 
something I happen to be working on, but it seems like the way to do 
this isn't exactly straight forward.  In my opinion a unit system 
library in the boost family should answer the runtime question at least 
as far as providing a documented and relatively easy method for doing so.