Re: [boost] [review] forwarded comments on pqs

From: Andy Little (andy_at_[hidden])
Date: 2006-06-09 11:11:14

"Thorsten Ottosen" <thorsten.ottosen_at_[hidden]> wrote in message 
news:44894631.8020602_at_dezide.com...
> 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):

Ok.

> 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.

Well.. at least it sounds like PQS covers your current functionality!

>  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.

The main utility I see is for debugging, logging,data tracing etc.
PQS I/O is modular so you dont need to include it unless you want it.

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

Its true that the current output format is fixed, but I disagree that this is 
because of the compile-time types. A locale facet type functionality has been 
suggested for internationalisation. compile-time types dont rule that  out 
AFAICS.

> 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.

FWIW this syntax is trival in PQS:

    typedef pqs::length::m length;
    typedef pqs::time::s time;
    typedef pqs::velocity::m_div_s velocity;

    length meter(){return length(1);}
    time   second(){return time(1);}
    velocity x = 10 * meter() / second();

   IOW If you prefer to work this way you can.

> 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.

Thanks for the review.

regards
Andy Little

>
> Kind regards
>
> Jesper

----------------- Original message:
Jeg nede lige at kaste et kort blik Andy's forslag mens jeg stadig var
under sydlige himmelstrg (jeg skulle nok have lavet et review mens jeg
holdt orlov). Mit umiddelbare indtryk af forslaget ud fra den
medflgende dokumentation var dog noget blandet. Jeg fler at forslaget
er undigt komplekst i forhold til de andre lsninger jeg kender
(inklusivt vores eget forsg).

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 ovenstende forslag. Specielt finder jeg
alt maskineriet omkring formatering af input og output for undvendig.
Fysiske strrelser bruges typisk i forbindelse med process kontrol, hvor
de primre IO enheder ikke er cin og cout. Hellere ikke i forbindelse
med HMI har vi haft brug for den stream support som forslaget tilbyder.
  Tvrtimod nsker vi ofte internationalisering, hvilket harmonerer
drligt med et output format, der er styret af compile-time typer. Helt
generelt har jeg svrt ved at forst motivationen for at indfre unit
typer frem for blot quantity typer. Personligt fortrkker jeg "length x
= 10 * meter() / second()" frem for "length::m_div_s x(10)" fordi det
frste minder mest om den syntaks vi kender fra det virkelig SI system.

P en eller anden mde fler jeg at Andy's lsning er et skridt i den
forkerte retning i forhold til de to ovenstende artikler.
Abstraktionsniveauet fles lavere selvom implementationen formentlig er
mere kompleks. Jeg synes jeg mangler et rationale, der beskriver hvorfor
Andy vlger et interface, som afviger fra "mainstream" lsningerne p en
rkke fundamentale omrder. Hvis argumentet for at indfre unit typer
alene er at kunne understtte C++ standard streams direkte, s kan jeg
ikke sttte forslaget.

Med venlig hilsen
Jesper
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost