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))
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk