From: Martin Schulz (Martin.Schulz_at_[hidden])
Date: 2007-03-27 05:52:49
excatly what places in your program are you talking about?
IMHO, I think we need to differentitiate a bit.
In those places that the templated approach works well (let us call that place "computation kernel"), you should pick and fix a consistent unit system first and then do your calculations.
Most of the time, you will not need any conversion there. Any deviation from that rule may get close to asking for trouble sooner or later, so you should have very good reason to do so. Thus only explicit conversions would be fine there; I'd rather go even further and not provide any conversion between templated quantities at all.
However, when it comes to interaction with users, things are completely different: There, the main benefit comes from flexibility and ease of use and this is where a templated approach seems too restrictive to me. I simply cannot tell what unit my users will want to input and output their data lateron. In that area, easy and correct conversions are what a unit library is all about; thus I would strongly vote for an implicit conversion there.
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Deane Yang
Sent: Montag, 26. März 2007 22:14
Subject: Re: [boost] [Review] Quantitative Units library review begins today March 26
Steven Watanabe wrote:
> From an implementation standpoint the only difficulty is in making a
> mixed system such as inches * miles / furlongs work without ending up
> with a mess.
Please take everything I say with a gigantic salt crystal, but I would want to forbid an expression like "inches * miles / furlongs". You might recall that I am one of the few who wants explicit unit casting.
I really should step out of this discussion. What you guys have done is extremely impressive, but it appears to be much more complex than anything I want. I just wanted to express my agreement with Zach's views.
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk