"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:44894631.8020602@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