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,ca15935e4fb21334 X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: Storage space question Date: 1998/12/11 Message-ID: #1/1 X-Deja-AN: 421013572 Sender: matt@mheaney.ni.net References: <366FE278.FAF73497@pwfl.com> <74pfg4$3s6$1@nnrp1.dejanews.com> <36704ADB.73FA308D@pwfl.com> NNTP-Posting-Date: Thu, 10 Dec 1998 17:21:07 PDT Newsgroups: comp.lang.ada Date: 1998-12-11T00:00:00+00:00 List-Id: Marin David Condic writes: > I've done exactly this in any number of situations. Enumerations are > definitely "The Ada Way" of solving this problem, so naturally you want > to try to do this. I don't necessarily agree. Giving enumeration types a representation clause seems to be of dubious value. > If you can't find an answer in the compiler-specific documentation, you > can always get there through the > less-desirable-but-no-worse-than-C-does-it method of declaring a bunch > of named numbers: > > Some_Name : constant := 2#0101# ; But that's going too far, because you've turned off all the type checks. A middle position between named numbers and enumeration types is constants of a integer type: type Robot_Control is range 0 .. 3; Run_Robot : constant Robot_Control := 0; Stop_Robot : constant Robot_Control := 1; Turn_Robot : constant Robot_Control := 3; type Control_Register is record ... Control : Robot_Control; ... end record; As long as you only use the constants (not the literals), you get all the type safety that an enumeration type buys you. Which is why rep clauses for enumeration types is overkill, that adds unnecessary complexity to the language.