From: Leland Brown (lelandbrown_at_[hidden])
Date: 2006-06-07 17:39:25
Gerhard Wesp <gwesp <at> google.com> writes:
> I think that handling of dimensional quantities and conversion factors
> are orthogonal concepts and should be separated.
An interesting idea. It might also help with some of the confusion about the
purpose of the library.
> I suggest that for maximum transparency the library should *exclusively*
> handle quantities expressed in SI units.
> Conversion factors between non-SI units and SI units should be constant
> dimensional quantities, e.g. (assuming constructors from double):
> const length foot = .3048 ; // Meter
> const power european_horse_power = 735.4987 ; // Watt
> const mass pound = 0.4535924; // Kilogram
> // ...
> This way, one could e.g. construct dimensional quantities like this:
> const power deux_chevaux = 2 * european_horse_power;
Yes! That is the way I like to see construction of dimensional quantities. Cf
> length x = 1000.0 * meter;
> velocty v = 2.0 * nautical_mile / hour;
BUT - the difference is, I would like to see the compiler enforce this sort of
strong typing and self-documenting for SI units also (as in my "meter" example
above). Otherwise, if SI quantities can be constructed directly from double,
nothing stops me from doing:
force f = 10.0; // kg
which is an undetected error because I apparently intended kg which is not a
force unit. I prefer requiring:
force f = 10.0 * kilogram; // error will be caught by compiler!
const length foot = .3048 * meter;
FWIW, when I wrote the equivalent of the (so-called for now) t2_quantity, I
implemented it exactly as you describe, keeping all quantities exclusively in
SI units, but kept that fact hidden from the user in order to prevent direct
conversions from built-in types and require the user to document his units, SI
Likewise, similarly to your other example:
> length altitude;
> double altitude_ft = altitude / foot;
I would write:
double altitude_m = altitude / meter;
if I needed the value as a nondimensional "double."
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk