Re: Storage space question

[dennison@telepath.com]

In article <9v6hGdgMLuwN-pn2-v5sq1RxFJ1z1@dt182n2f.tampabay.rr.com>,
  cpallen@nospam.com (Craig Allen) wrote:
> Hello!
>
> the short version of my question is this:  If I'm using enumerations
> to
> define names that will represent specific bit patterns that my program
> may
> wish to use, do *all* these bit patterns allocate space? e.g.  with
...
> is space allocated for each of these definitions?  I ask because I
> added
> many of these types to a package I'm writing, and my memory map seems
> to
> have grown even without using these types yet.

There is an attribute available for every enumeration type, "'image", which
returns the string reprenentation of a given enumeration value. If you think
about it, the only way to implement this is to build a mapping between the
enumeration values and the strings which is consulted whenever "'image" is
called. This mapping *has* to contain the strings, and *has* to be stored in
your program somewhere.

If you don't want that to happen, and can live without 'image and 'value,
many Ada compilers provide a pragma to prevent generation of the mapping.
Check your vendor docs for more information.

There is also an attribute, "'pos", which will return the position number of
an enumeration value. Since a record representation clause makes the value
represeted by an enumeration different from its position number, a mapping
between those must be created as well.

Enumerations can't be handled like "#defines" in C because they are actual
values, which may be stored in variables. A compiler may be able to tell you
what "Boolean'image(TRUE)" is at compile time, but in order to tell you what
"Boolean'image(My_Boolean_Flag_Variables)" is, a table will have to be
consulted at runtime.

If you truly need the low overhead untyped C approach (yuk), integers and
named numbers are the way to go (in Ada 83). But I'd try turning on compiler
size optimizations first. If your executable is *still* too big for the
target after that, then worry about mangling your code. (I assume you aren't
looking to micro-optimize your souce code as you design it, which is almost
always a bad idea).

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own