Efficiency of code generated by Ada compilers
in [ADA]
|
Prev: 100% without investment online part time jobs..(adsense,datawork,neobux..more jobs)
Next: installing SPARK GPL on Windows
From: Charles H. Sampson on 11 Aug 2010 03:42 <tmoran(a)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
From: anon on 11 Aug 2010 07:58 In <8cf0fkF60rU1(a)mid.individual.net>, Niklas Holsti <niklas.holsti(a)tidorum.invalid> writes: >Yannick Duchêne (Hibou57) wrote: >> Le Wed, 11 Aug 2010 01:28:25 +0200, Yannick Duchêne (Hibou57) >> <yannick_duchene(a)yahoo.fr> a écrit: >>> In “11.5 Suppressing Checks”: >>> 4/2 pragma Suppress(identifier [, [On =>] name]); >> Strange. I've noticed it with the reply to you : the “[, [On =>] name]” >> appeared in the message while it is not visible in my reference. May be >> some trouble with the HTML version I use. > > [ snip ] > >> This is no more valid Ada (well.... this is still valid Ada 95, this is >> just not more valid Ada 2005/2012) > >In the Ada 2005 RM, see section J.10 (Obsolescent Features: Specific >Suppression of Checks). > >-- >Niklas Holsti >Tidorum Ltd >niklas holsti tidorum fi > . @ . Since, all Ada compilers except for GNAT and IBM are still using Ada 83 or 95 standard the "pragma Suppress ( identifier [ , [ On => ] name ] ) ;" statement is still valid. Plus with GNAT having all of the standards within one compiler, GNAT should allows this version plus the new version as well.
From: Georg Bauhaus on 11 Aug 2010 08:37 On 11.08.10 13:58, anon(a)att.net wrote: > Since, all Ada compilers except for GNAT and IBM are still using Ada 83 or > 95 standard the "pragma Suppress ( identifier [ , [ On => ] name ] ) ;" > statement is still valid. The AppletMagic compiler (using the AdaMagic front end) has let me see some hints to Ada 2005 features a few years ago. So I think it is safe to assume that AdaMagic supports Ada 95, and Ada 2005 to some extent. (Another possible hint is, I think, its being used in a current project in Britain IIRC, an embeeded one. Someone reported here, recently.) Georg
From: Robert A Duff on 11 Aug 2010 09:13 Niklas Holsti <niklas.holsti(a)tidorum.invalid> writes: > Yannick Duch�ne (Hibou57) wrote: >> This is no more valid Ada (well.... this is still valid Ada 95, this >> is just not more valid Ada 2005/2012) > > In the Ada 2005 RM, see section J.10 (Obsolescent Features: Specific > Suppression of Checks). Right. And things in the "Obsolescent Features" annex are perfectly good Ada, and all Ada compilers are required to support them. These features are "obsolescing" so slowly that they will never actually become "obsolete". ;-) That's my prediction, given that I've never heard anyone on the ARG suggest that they should eventually be removed from the standard. - Bob
From: Robert A Duff on 11 Aug 2010 09:38
csampson(a)inetworld.net (Charles H. Sampson) writes: > <tmoran(a)acm.org> wrote: >> Bearing := (Bearing + Turn_Angle) mod 360; > > I'd be interested in hearing reactions to something I did. ... > 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 "+". Sounds to me like a good way to do things. It would still be a good idea if you called it "Turn_Left" or something like that, instead of "+". But I don't object to "+". I object to having built-in support for angle arithmetic in the language, though. Did you eliminate meaningless ops like "*"? You could do that by making the types private, but then you lose useful things like literal notation. Or you could declare "*" to be abstract, which is an annoyance, but might be worth it. - Bob |