Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk