Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2004-01-07 15:42:18


"Andy Little" <andy_at_[hidden]> wrote in message
news:bthfla$ah8$1_at_sea.gmane.org...
> [...]
> code redone with pqs-100-01 syntax below (compile checked
> only)

Ok, looking at your code, several things occur to me. 1) You really
do need a way to specify the unit/quantity in the type, for declaration
purposes. I still don't like your syntax, because it doesn't look
intuitively extensible. For instance, is the user supposed to provide
all the unit combos for a given dimensional quantity, like velocity?
Is the user expected to add ft_per_s, mi_per_hr, km_per_hr, etc.,
ad nauseum, to q_velocity? It seems that a composition approach,
as described by others would be more flexible. I understand that
it's also more complicated, but sometimes, you need to spend a
little simplicity to get a good result.

2) The postfix unit syntax makes the most sense for constant literals.
And, more likely than not, such literals are probably very rare. Even
worse, they will probably be named as common physical constants,
at which point they can be predeclared with the correct units. So it
seems that the more common case for postfix units would be
converting a pure value to a unit-ed value, such as during input. Of
course, if someone were to overload stream operators for units/
quantities, then even that application might go away. Which just
leaves us with the case where you get the numbers from code which
doesn't use a units/quantity library. And will probably only occur on
an interface boundary, and be dwarfed by the number of occurrences
of values whose units are pre-declared, like your code. So even
though I think postfix syntax would be nice, it doesn't seem to be
as important as I suspected.

3) There is a redundancy to your system which can be good or
bad. You shouldn't have to say that m_div_s is a velocity. On
the other hand, for very short names, like m or s, spelling out
the dimension could be useful. It seems to me that perhaps
users would typedef the most commonly used units, in which
case it might not be bad to give them longer names, like so:

typedef div<meters, seconds> velocity;

On the other hand, that hides the unit system, which might make
it easier to accidentally interchange units when you really wanted
a conversion. So I guess my conclusion is that C++ just isn't
quite up to the task of making a really nice units/quantity library,
and we'll just have to argue over the compromises. What I think
would really help is if C++ allowed const UDTs to be compile-time
constants. Then you could do things like:

unit<m/s> Vw;

But obviously, we can't wait for something like that.

> [...]
> struct chord_omega{
> // 2nd param should be q_angle::rads
> chord_omega(q_length::m,double){}
> };
> [...]

Just a nitpick, but most people would spell this:

typedef std::pair<q_length::m, q_angle::rads> chord_omega;

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk