Re: [boost] [Review] Quantitative Units library review begins today March 26
AMDG Deane Yang wrote:
Zach Laine wrote:
Specifically,
quantity<force> F(2.0*newton); quantity<length> dx(2.0*meter); F.value() = dx.value();
is an abomination and should be impossible. If I really want to do this, why not make me go through the constructor, so that attention is more obviously called to what I'm doing? I could also live with using a purposely ugly cast here, but since quantity_cast() has some perfectly legitimate and safe uses, I would much prefer a different syntax that draws attention to this unsafe act, such as quantity_reinterpret_cast().
I agree completely with Zach's views on this. It's OK to have a const member function .value() but not a mutating one.
I and a lot of other users badly need support for Imperial units. As it stands now, we will each be required to write nearly identical code to do so. This should be included in the library.
Matthias Schabel wrote:
The problem with these non-standard units is that they don't really form a well-defined unit system. ... We have, however, supplied a number of examples of how to roll your own unit system... )
I agree with Zach and also want to be able to define units without having to "roll my own unit system".
I have contemplated something along the lines of //this is what you need to do already //to get feet struct foot_tag {}; template<> struct unit_info<length_tag, foot_tag> { static const char* name() { return("foot") } static const char* symbol() { return("ft") } }; //converting feet to meters template<> struct base_unit_converter<length_tag, foot_tag, SI::system_tag> { typedef double type; static type value() { return(...) } }; //converting meters to feet template<> struct base_unit_converter<length_tag, SI::system_tag, foot_tag> { typedef double type; static type value() { return(...) } }; Now feet are defined independently of other base units and can be easily combined with any other set of units: typedef make_system< mpl::map< mpl::pair<length_tag, foot_tag>, mpl::pair<mass_tag, SI::system_tag>, mpl::pair<time_tag, SI::system_tag> >
::type FKS_system; (feet-kilograms-seconds)
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. In Christ, Steven Watanabe
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. Deane
AMDG Deane Yang <deane_yang <at> yahoo.com> writes:
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 prefer explicit too. The expression "inches * miles / furlongs" doesn't do any conversion. It returns a type that encodes the combination. If you want the result in inches you have to explicitly cast. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
I prefer explicit too. The expression "inches * miles / furlongs" doesn't do any conversion. It returns a type that encodes the combination.
That would be fine with me!
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 think one of the important things to note is that our implementation allows the user fine-grained control of unit conversion - the default is explicit only, but it is possible to specify that certain units are implicitly convertible. For example, if I write quantity<SI::length> L1(1.5*inches*miles/furlongs); This will compile and give a correct answer if and only if there is a conversion (implicit or explicit) for each of the length units on the right. Matthias
Deane, 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. Yours, Martin. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Deane Yang Sent: Montag, 26. März 2007 22:14 To: boost@lists.boost.org 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. Deane _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Deane Yang -
Martin Schulz -
Matthias Schabel -
Steven Watanabe