Subject: Re: Beware: Rep spec on an enumeration type causes code explosion
From: Robert Dewar, dewar@merv.cs.nyu.edu
Date: 6 Dec 1997 11:43:29 -0500
Tuck said

<<As far as enumeration types, as others have pointed out, the Ada 95
standard requires that the internal codes for enumeration types are
contiguous and start at zero, so you are not in any danger if you leave
out your "confirming" representation clauses.  It would be nice if
our front end recognized "confirming" enumeration representation
clauses, but as usual, there are many possible "optimizations"
and this one never made it to the top of the list.
One might argue that this is not really an optimization, but
it does require special code to recognize, and so represents
yet another "special case" that you have to decide the priority
of recognizing.
>>

We found pretty early on with GNAT that a *lot* of legacy code uses
these confirming representation clauses. This is not unreasonable. In
Ada 83 there is no guarantee that the default representation is zero
based and contiguous, and moreover the official definition of Standard
contains the following:

  for CHARACTER use  --  128 ASCII character set without holes
       (0, 1, 2, 3, 4, 5, ..., 125, 126, 127); 


which certainly creates the impression that it is good style to add
these confirming representation clauses. Indeed I would argue that it
is still good style to add them in Ada 95 as a way of documenting and
emphasizing that you are depending on the representation.

In any case, the fact is that a lot of code *does* contain this optimization,
which is why we are careful in GNAT to make the definition of "enumeration
with holes" be a situation in which the representation disagrees with the
pos for at least one literal, rather than the presence of an enumeration
representation clause. We have found that this optimization makes a critical
performance difference for more than one of our customers.

Robert Dewar
Ada Core Technologies