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

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

Matthias Schabel wrote:
> Hi Noah,
> 
>> Would something like this work for creating a quantity that's unit can
>> change during runtime and allow support for multiple units all
>> converting to a particular "system" (as you specify the meaning)?
> 
> I am drawing a "line in the sand" at implementation of runtime unit  
> systems;
> this is not because it can't or shouldn't be done, but because it is  
> basically
> a completely different problem domain with different objectives and
> performance criteria.

I think it is a definite must that any unit library needs to be at least 
extensible to support the two problems I described.  I personally don't 
see much use in being able to convert, statically, between two disparate 
unit systems.  I don't know of any project that would do this.  Perhaps 
for times when you are using third party libraries that assume one set 
of units while you work in another this would be necessary but that 
doesn't seem a general enough problem for a boost library and both would 
have to use this system.  The primary goal of a boost units library 
should be to support safe unit conversions of user defined units in a 
way that ensures that conversions are safe and inexpensive (as in not 
done more than once per assignment) and the primary use of this will be 
during runtime.

I was hoping that your library could be used as a base for such a 
runtime solution but you make it sound like more trouble than worth.  I 
will probably continue to look at ways to work this in, especially if 
you get accepted, but since I already have a very simple answer to the 
problem it may be placed on the back burner.  It would be nice to be 
positive that units share the same base system and provide a general 
solution when they might not but I really think, practically speaking, 
that the likelihood of someone needing to have two different static base 
systems is next to nil.

I don't believe Andy's problem was that runtime units are too large a 
problem but that these unit libraries try to do too much in static mode. 
  It certainly makes for a great excercize in tmp but without support 
for conversions to arbitrary, runtime selected, units I don't see how 
they have a whole lot of practical value.  By support I mean either 
built in or easily extended in a well documented manner.

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.