[boost] Re: Physical Quantities revisited

From: Andy Little (andy_at_[hidden])
Date: 2003-10-25 15:40:18

"Jan Langer" <jan_at_[hidden]> wrote in message
news:bndk42$97m$1_at_sea.gmane.org...
> Andy Little wrote:
> >>and what should be the return type of an addition of kilometers and
> >> inches.
> >
> > using your scheme I have absolutely no idea... :-)
>
> as i already wrote i'd like to see a lib where everything is calculated
> in measures of the fundamental unit.

There are various views on this,higher in the thread.

and i haven't tried to implement my
> own units library. i really think there should be agreement on certain
> basic design things.
the existing librarys differ very much from each
> other and each has certain ideas which might be good for ohers too.

Yup!

>
> >  Try here for an answer:
> > http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html
>
> i looked at the implementation and found the surprising answer that you
> just take the units of the first operand. but consider the example:
> kilometers + meters
> a user might think that a value_type of int is sufficient for his needs.
> then he adds 2 kilometers and 5 meters and he gets 2 kilometers.
 if he
> does it the other way round he'll get 2005 meters. thats quite
error-prone.

as you say
pq_length<int>::km lengthA(2);
pq_length<int>::m lengthB(5);
std::cout << lengthA + lengthB << '\n';
std::cout << lengthB + lengthA << '\n';

gives:
2 km
2005 m

Yep  this is probably not the ideal solution !
And its an important point
It would probably be better to follow the bindings in the grammar
 Or maybe there is an algorithm that works out the " physical_quantity
promotion" during a calc.
This would involve the units and scaling.
, perhaps taking account of scaling factor powers etcetera,
however too much complexity may  alienate the programmer, bearing in mind
more complex pqs ie force
At this stage I note your points. Any view or preferences on "semantics"
(think is the right word for this)
of what should happen appreciated.
The best way would probably be the one that feels  intuitively right ... in
the spirit of C++.

>
> if he explicitly says "i want to calculate in kilometers" somewhere it
> would be ok. because then also 5 meters plus 2 kilometers gives 2
> kilometers.

I dont like the idea of holding state outside the entity.
 The major purpose of the type is type checking.
 This is a lightweight type,
or "concrete type" as described in C++ 3rdEd. with consistent semantics.
 If you can modify its properties on the fly you have to
keep checking their current state. ie its not a strong type any more.

Unit conversion is fun in the demo but should be avoided unless absolutely
necessary.

However I strongly agree that the semantics need to be defined better than
they are in the demo as it stands