Re: [boost] Re: Unit library

From: Phil Richards (news_at_[hidden])
Date: 2004-01-13 14:25:10

On Tue, 13 Jan 2004 13:46:39 -0500, Deane Yang wrote:
[rest snipped - I'll reply in more detail when I'm not cooking dinner!]
> (By the way, my other reaction to the ambiguity of "force * length" is
> that the usefulness of overloaded operators is probably overrated. Each
> operator* probably should be replaced by a function with a more
> informative name. For example, in the world of finance, there are two
> different types of multiplication, multiplication by a discount factor
> and multiplication by a probabiliy. I find it quite useful to
> distinguish between the two by using two different functions, even
> though 99% of the time the two functions do exactly the same thing.
> Otherwise, the remaining 1% is a real killer. It has the added benefit
> of making the code easier to understand.)

I think in this particular case you *don't* want dimensional analysis at
all - you want the good old-fashioned "let's define the operators we need
on the things we need" approach.  This would be achieved simply by giving
the value "unit" but no dimension - and what we would want is that the
library would not allow implicit conversion between dimensionless things
with different unit.

Maybe something like:
 struct apple_u { ... }; // unit of apple
 struct orange_u { ... }; // unit of orange
 typedef quantity<int, dimensionless, apple_u> apples;
 typedef quantity<int, dimensionless, orange_u> oranges;

Then:
 apples a1(4);
 oranges o1(3); // ok
 apples a2 = a1 + apples(7);

But:
 oranges o2(a2); // fail to compile
 oranges o2 = a1 + o1; // fail to compile

As you say, all the more complicated stuff would be explicitly written.
(No, my library doesn't work this way :-)

phil
-- 
change name before "@" to "phil" for email