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