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