Re: [boost] mcs::units informal review request

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-13 12:52:56

Michael Fawcett wrote:
> On 2/13/07, Noah Roberts <roberts.noah_at_[hidden]> wrote:
>> Janek Kozicki wrote:
>>> Matthias Schabel said:     (by the date of Tue, 13 Feb 2007 00:20:09 -0700)
>>>
>>>> quantity<SI::length> getInput(const unit_enum& input_unit,double val)
>>>> {
>>>>      typedef quantity<SI::length>    return_type;
>>>>
>>>>      switch (input_unit)
>>>>      {
>>>>              case FEET       : return return_type(val*imperial::feet);
>>>>              case LEAGUES    : return return_type(val*nautical::leagues);
>>>>              case METERS     :
>>>>              default         : return return_type(val*SI::meters);
>>>>      };
>>>> }
>>> I like this approach.
>>>
>> I wouldn't recommend it.  It doesn't scale too well.
> 
> I too like the approach.  I'm curious how it doesn't scale well.

Well, I should say in our case it didn't.  You end up with several large 
functions with long lists of case statements and then separately, 
somewhere, a list of conversion factors.  In this case we are talking 
about a static unit converter somewhere, and correct me if I'm wrong but 
I think they are in several different tables...not just tables for each 
dimension you will be doing conversions in but in different "systems".

Add the enum...it just became nightmarish or I wouldn't be looking for a 
new way to do these things.  Any time you have 2 or more things that 
need to be modified in parallel I find there is bound to be 
difficulties.  Hence the desire to merge it all into one concept.

I like the idea of systems in order to ensure that the same base unit is 
used in all places but I don't like the idea of having to make several 
systems for all the different units a user might want to have their 
reports in.  I don't think that will scale too well either.  For 
instance, we have probably 20+ units for measuring pressure alone.

I don't like the idea of getting rid of casts to make this work.  The 
casts ensure that you are not doing conversions in the middle of 
calculation cycles.  This is important to us because in our set of 
products there are several complex calculations performed in loops and 
even on todays computers you feel the hit.  Enforcing a base system 
ensures conversions are done outside of this area in a pre/post manner.

But without enabling implicit conversions and removing that barrier it 
looks like doing the other things I need doesn't work too hot.

   With
> the existence of some runtime support (for which I agree with others,
> should not be in this iteration of the library) and the programmer's
> acceptance that it would incur overhead, how would you implement that
> function?  Wouldn't you still need the switch?

I wouldn't make the function.  There needs to be a way to set up a set 
of unit converters that are attached to the value and will do the 
conversion when needed.  I personally prefer on assignment and have 
found, so far, that this works.

Frankly put, I don't have a use for a library that does static unit 
conversions.  We work in one system of units and convert into/out of 
those units when required to arbitrary units the user specifies and 
there are of course only a few dimensions we do this in.  I have a hard 
time seeing a situation in which this isn't the way you would want to go 
about it.