Re: Unchecked_Conversion

[Ted Dennison<dennison@telepath.com>]

In article <41F37C284A6DE8C0.8A6A99719FF11B52.8149DC60E20677C9@lp.airnews.net>,
Robert B. Love  says...
>
>In <LdLT6.2225$bA3.107918@www.newsranger.com> Ted Dennison wrote:
>> Just to back up Marc here, you should almost *never* have to convert 
>types. The
>> only times I ever have to do it are when interfacing with external 
>routines that
>
>My experience runs counter to this.  My employer has chosen to use
>typing for every conceivable measurement. So we have type Meters, 
>Meters_Per_Second, Feet, Feet_Per_Second, Seconds, Watts, Volts, and so 
>on.
>The list is endless.


I'm sorry. There was an implied "with unchecked_conversion" in there. I often
perform type conversions between numeric types or derived types.

As for the particular (quite different) issue you are talking about: I've worked
with various groups that had to deal with engineering units, and they all tend
towards the same conclusion. You can either use "integer" and "float" for
everything, or you can make a separate type for each and every unit and
intermediate unit you will ever need, along with your own overloaded operators
for every operation that you will ever perform on any combination of them. Any
wishy-washyness in the middle just causes headaches of the kind you have
described.

As the "separate type for everything" route is almost always prohibitive,
usually folks opt for the minimalist route. Of course it can still be a good
idea to use constrained subtypes, esp. for routine interfaces. There can also be
a case for making separate types in certain cases where you want something
special done and don't mind rewriting all the operators to work with integer or
float to achieve that goal (eg: a Degrees type that automaticly does a "mod 360"
on any operator result).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com