Michael Fawcett wrote:
On 2/13/07, Noah Roberts <roberts.noah@gmail.com> 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.