From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: gwinn@res.ray.com (Joe Gwinn) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/16 Message-ID: #1/1 X-Deja-AN: 298739226 Content-Transfer-Encoding: 7bit References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Raytheon Electronic Systems Newsgroups: comp.lang.ada Date: 1997-12-16T00:00:00+00:00 List-Id: In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Joe says > > < realtime use. We will invent some such solution as you suggest.>> > > No, that's wrong. If you do nothing but assignments and comparisons, there > is no overhead in the use of enumeration types with holes. If you index > compact arrays, or worse, do Succ or Pred, then you should have an > implementation model which tells you immediately that there is extra > overhead. This should not be a mystery. I was talking about rep specs on enumeration types. > Similarly, how could you possibly be surprised that x'Image(a) causes > a formatted conversion, THAT IS WHAT IMAGE IS ABOUT. There is no resaon > to forbid this. If you need the function of Image, you should use it, if > not you should not. I must say I find the comment on Image *very* odd! Umm, the point was that many programmers were not aware of the runtime cost of tick-Image, not that tick-Image was inherently bad. I had the same problem with fortran programmers wanting to use encode in realtime programs. I recall getting an argument when I forbade the use of encode in the late 1970s; it turned out that the core issue was that some of the programmers didn't recall how to write a binary<->decimal conversion routine, but were afraid to admit it. A few pages copied from Knuth solved the problem. In those days, most of the embedded realtime programmers were retread hardware engineers who learned to program by reading the language and computer manuals. So, the core issue comes down to having some kind of idea of what various language features and idioms cost in memory and CPU time at runtime. This issue is relevant to all languages, especially complex and capable ones such as Ada95 and C++. Simpler langauges, such as fortran and C, seemed to have fewer surprises. It certainly makes sense that this should be so. Joe Gwinn