Re: Efficiency of code generated by Ada compilers

[csampson@inetworld.net (Charles H. Sampson)]

<tmoran@acm.org> wrote:

> > And it would be desirable, because in most cases the explicit
> > "mod" (or "%") is more readable.
> 
>    I := Ring_Indices'succ(I);
> vs
>    I := (I + 1) mod Ring_Size;
> or
>    Bearing := Bearing + Turn_Angle;
> vs
>    Bearing := (Bearing + Turn_Angle) mod 360;

     I'd be interested in hearing reactions to something I did.  About a
year ago I had reason to do something similar to the Bearing/Turn_Angle
example.  To avoid having to do a lot of background, I'll just restate
what I did in terms of Bearing/Turn_Angle.

     Bearing and Turn_Angle as integers are way too inaccurate for the
application I was working on, which involved real-time position
calculations at a high rate.  So Bearing and Turn_Angle were defined as
two (distinct) types derived from Long_Precision.  (They were defined as
types because "Bearing" and "Turn_Angle" are non-specific nouns.  See
the Ada Style Guide.)

     I then overloaded "+" and "-" for (Bearing, Turn_Angle) arguments
and Bearing return value.  In those functions is where the mod 360
occurred.  (Actually, mod 360.0, as it were.)

     There were two advantages to doing that.  The more important was
that previously both of the kinds of values were being represented as
subtypes of Long_Precision and programmers would occasionally
interchange them and cause big debugging problems.  The second was
removing the "mod" from sight, which allowed the programmers to simply
think of taking a bearing, turning an angle, and getting the resulting
bearing, without worrying about all the niceties that might be going on
inside "+".

     Of course, new programmers coming on the project had to be taught
about the overloads and that they should not be writing elaborate
if-then-elses when they wanted to turn the ship.

                        Charlie
-- 
All the world's a stage, and most 
of us are desperately unrehearsed.  Sean O'Casey