Boost logo

Boost :

From: eford_at_[hidden]
Date: 2001-09-15 12:38:19

> So you are in agreement that the units themselves aren't of great
> importance to the programmer in these settings? Just the

I'm not entirely sure what that means, so I don't want to give a yes
or no answer. I know that I would like to be able to write functions
which take and return quantities with dimensions and units. I want to
specify the dimensions and get compile time errors if they don't
match. I don't want to specify units in the functions. I want the
compiler to do the "right thing".

It sounds to me like there may be several design decisions:

1a. Generate compile time errors for dimension mismatches, perform
automatic unit conversions (e.g. SIunits)
1b. Generate compile time errors for dimension and unit mismatches, no
automatic unit conversions

I like 1a, but see the reasons for both. Would there be a good way to
have one code base and allow the programmer to specify which behavior
they wanted?

2a. Have a fixed set of dimensions (e.g. 7 in SIunits)
2b. Allow users to add their own dimensions

You might be able to provide 2b by having three template arguments for
each dimensioned quantity, a numerator list, denominator list, and a
list of which dimension.

However, allowing users to add their own dimensions seems dangerous to
me. Because some silly user is going to think "I have a distance and
time dimension, but I need a velocity dimension." You might argue
that they shouldn't be using automatic conversions (or even writing
the code), but there are less obvious cases and I can imagine users
creating redundant dimensions and causing problems with checking for
the same dimension.

At the same time, I can see the desire for things like "a teaspoon of
sugar". But I'm not sure that it's a good idea to think of the
ingredient as a dimension or unit. I wonder if you could combine one
library with choices 1a, 2a and another with choices 1b, 2b in series
to that effect. So I'd say something like
  typedef enum { sugar = 100, flour = 101 } ingredients;
  typedef unit_unconvertible<teaspoon, ingredients::sugar>
  typedef unit_unconvertible<tablespoon, ingredients::sugar>
  typedef unit_unconvertible<cup, ingredients::flour> cup_of_flour;

Then conversions between different "of sugar" units would be
automatic, but conversions between any unit of sugar and any unit of
flour would generate compile time errors.

3a. Have a fixed set of conversions (e.g. SIunits)
3b. Allow conversions that are dynamically specified at runtime (e.g.

I think for scientific users, 3a is the only reasonable choice.
However I'd guess that for financial users, 3b is the only reasonable
choice. Is it possible/reasonable to have one code base that deals
with both efficiently? That might could be done with a trait type
parameters, but it also might get messy. Maybe multiple separate
libraries (e.g. SIunits-like, unit_unconvertible-like, currency-like)
are in order. In that case, we'd want to make sure they can interface
with each other (e.g. dollars per pound and euros per kilogram).


Boost list run by bdawes at, gregod at, cpdaniel at, john at