Boost logo

Boost :

From: Deane_Yang_at_[hidden]
Date: 2001-08-14 08:29:21

Disclaimer: I haven't had the time to examine the submitted
libraries, so my comments might be completely irrelevant.

As I've mentioned before, I prefer to keep things very simple.
The other proposals I've seen appear to be much more

I've found it useful just to define a separate class for each unit
and a separate function for each conversion that I need.
My unit classes derive from a template base class that
defines common features (addition, subtraction, comparison,
etc.). The "user" of this template can define any units and
conversion he/she needs.

In other words, I follow the "don't please anyone" approach
mentioned below.

So my code looks something like this:

Feet length_in_feet(12);


typedef Ratio<Meters,Seconds> MetersPerSec;
typedef Ratio<Meters,Hours> MetersPerHour;

// It would be better to use an overloaded operator/ here
MetersPerSec velocity(length_in_meters, Seconds(10));


Seconds time(20);
Meters distance(velocity * time);

-------------end of code------------------------

The implementation just uses template specialization and is
totally straightforward.

I don't try to implement commutativity and associativity
fully, so some formulas won't compile. But that's easily fixed
either by rearranging the factors or inserting parentheses.

I'm more concerned about making sure that bad formulas do
NOT compile. I have found my classes very effective for that.
I've used it mainly in implementing financial valuation libraries
(bonds, options, swaps, etc.), where it is convenient to use
different units of time in different contexts.

--- In boost_at_y..., Anatoli Tubman <anatoli_at_p...> wrote:
> A quantity library that wishes to support both metric
> and English units must chose one of the following:
> 1. All length are stored in meters.
> 2. All length are stored in feet.
> 3. All length are stored in units specified at configure time.
> 4. Some lengths are stored in feet, others in meters.
> Every choice has its problems. Choices 1 and 2 are giving
> preference to users of a particular unit system.
> Choice 3 gives unfair preference to users of *two* particular
> unit systems (unless you are willing to support every
> unit system at configure time). Choice 4, like 3, gives unfair
> preference to two particular unit systems -- but now to be fair
> you have to either support every imaginable unit system at *
run* time,
> or support support every imaginable *set* of unit systems at
> time.
> We can see that it's hard to please everyone (surprise!). Given
> chosing an applicable international standard is one of more
> decisions.
> Another approach would be "don't please anyone". That is,
> *dimensionality* library and several independent *example*
> libraries (SI, English, Planck, whatever) on top of it. Users that
> unsupported units can supply their own unit library. Hopefully,
> ease.
> Fortunately, it is really easy to refactor the proposed quantity
> to support this last approach.
> On Monday 13 August 2001 21:41, Thomas Matelich wrote:
> [snip]
> --
> anatoli at ptc dot com -- opinions are mine

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