Re: Beware: Rep spec on an enumeration type causes code explosion

[gwinn@res.ray.com (Joe Gwinn)]

In article <dewar.882235092@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe says
> 
> <<I guess I would have to agree, because it's certainly too expensive for
> 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