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.