[boost] [review] forwarded comments on pqs

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-06-09 05:58:09

Hi Andy,

This is my tranlation of the brief comments of one of my Danish friends 
who has great experiance with unit-libraries:

--------------Translation begin:
I had a quick look at Andy's proposal while I was travelling. My
immediate impression of the proposal based on the documentation
was faily mixed. I feel that the proposal is unnecessary complex
compared to the other solutions I know (including our own):

Automatic Units Tracking (by Christopher Rettig)
Embedded Systems Design (marts 2001)

Dimension Checking of Physical Quantities (by Michael Kenniston)
C/C++ Users Journal (april 2003)

We have used compile-time SI types for the last 3-4 years in our
products (remark: software for windmills in the world largest windmill 
company) and I have never missed the
extra functionality Andy is offering compared to the two above 
proposals. In particular, I find all the machinary concerning
formatted I/O unneccessary. Physical quantities is often used in 
connection with with process control, where the primary IO units are not
cin and cout. Not even in connection with HMI have we had a need for the 
stream support the proposal offers.

On the contrary, we often want internationalization, which fits badly 
with an output format controlled by compile-time types.

In generel I have a hard time understanding the motivation for 
introducing unit-types instead of just quantity types. Personally I
prefer

   length x = 10 * meter();

to

   length::m_div_s x(10)

because the former is closer to the syntax from the real SI system.

At some level I feel Andy's solution is a step in the wrong direction 
compare to the above articles. The level of abstraction feels lower
even though the implementation is probably more complex. Jeg feel I'm 
lacking a rationale to why Andy has chosen an interface that deviates
from "mainstream" solutions on a number of key areas. If the argument 
for unit-type alone is to support C++ standard streams directly, I can't
support the proposal.

Kind regards

Jesper

----------------- Original message:
Jeg nåede lige at kaste et kort blik Andy's forslag mens jeg stadig var 
under sydlige himmelstrøg (jeg skulle nok have lavet et review mens jeg 
holdt orlov). Mit umiddelbare indtryk af forslaget ud fra den 
medfølgende dokumentation var dog noget blandet. Jeg føler at forslaget 
er unødigt komplekst i forhold til de andre løsninger jeg kender 
(inklusivt vores eget forsøg).

Automatic Units Tracking (by Christopher Rettig)
Embedded Systems Design (marts 2001)

Dimension Checking of Physical Quantities (by Michael Kenniston)
C/C++ Users Journal (april 2003)

Vi har brugt compile-time SI typer gennem de sidste 3-4 år i vores 
produkter og jeg har aldrig savnet den ekstra funktionalitet Andy 
tilbyder i forhold til de to ovenstående forslag. Specielt finder jeg 
alt maskineriet omkring formatering af input og output for unødvendig. 
Fysiske størrelser bruges typisk i forbindelse med process kontrol, hvor 
de primære IO enheder ikke er cin og cout. Hellere ikke i forbindelse 
med HMI har vi haft brug for den stream support som forslaget tilbyder. 
  Tværtimod ønsker vi ofte internationalisering, hvilket harmonerer 
dårligt med et output format, der er styret af compile-time typer. Helt 
generelt har jeg svært ved at forstå motivationen for at indføre unit 
typer frem for blot quantity typer. Personligt fortrækker jeg "length x 
= 10 * meter() / second()" frem for "length::m_div_s x(10)" fordi det 
første minder mest om den syntaks vi kender fra det virkelig SI system.

På en eller anden måde føler jeg at Andy's løsning er et skridt i den 
forkerte retning i forhold til de to ovenstående artikler. 
Abstraktionsniveauet føles lavere selvom implementationen formentlig er 
mere kompleks. Jeg synes jeg mangler et rationale, der beskriver hvorfor 
Andy vælger et interface, som afviger fra "mainstream" løsningerne på en 
række fundamentale områder. Hvis argumentet for at indføre unit typer 
alene er at kunne understøtte C++ standard streams direkte, så kan jeg 
ikke støtte forslaget.

Med venlig hilsen
Jesper