enums

Stan Friesen sarima at gryphon.CTS.COM
Mon Aug 1 05:50:47 AEST 1988


In article <11686 at steinmetz.ge.com> davidsen at crdos1.UUCP (bill davidsen) writes:
>
>- enums should be a sequence of values in increasing order. The values
>  should start at zero and increase by one. This allows the ++ and --
>  operators to be used in a meaningful way.

	Yes, at least if I can force deviation from this order if necessary,
such as making an enum to deasl with hardware generated values.
>
>- enums should not be conceptually mixed with ints. An explicit operation
>  should be required to extract the ordinal value of an enum, and to set
>  an enum to a value.

	Well, ONLY if you also redefine the syntax of the switch and case
statements to allow both ints and enums. If I cannot do a switch on an
enum where the case's have the enum constants as values an enum is almost
useless. (After all I doubt that "case (int)red" is legal even if I would
be willing to write such garbage). This is IMPORTANT. At least the ANSI draft
requirement that enums act like int's also gaurentees that switch/case usage
is legal and intuitive.
>
>- it would be nice to have separate namespace for the various enum
>  types. The current implementation treats enum names as if they were
>  #defined values. This was a good idea for structs, and it's a good
>  idea here. It allows development of modules wothout having to have a
>  master control for enum names. Statements like x=red would specify the
>  "red" for the enum type of x. enum type conversion could require a
>  cast.
	Very nice, I agree with my whole being.
-- 
Sarima Cardolandion			sarima at gryphon.CTS.COM
aka Stanley Friesen			rutgers!marque!gryphon!sarima
					Sherman Oaks, CA



More information about the Comp.lang.c mailing list