ps@celerity.UUCP (04/17/84)
I have encountered a problem using enumerations with the 4.2bsd C compiler. The System 5 C Programming Guide states that the current language treats enumeration variables and constants as being of *int* type. There are apparently no special constructs in the language for incrementing and decrementing enumeration variables, and declaring arrays indexed by enumeration types. I assumed that the correct way of doing this would be to use the equivalent integer operations. However, the attached program causes the following error messages: "testwk.c", line 18: illegal comparison of enums "testwk.c", line 18: operands of ++ have incompatible types "testwk.c", line 19: operands of + have incompatible types "testwk.c", line 19: illegal indirection The compiler appears to be complaining about all uses of the enumeration type other than simple assignment and equality comparison. Is this how it ought to be? If so, enumerations are unlikely to be very useful. The following operations seem to be necessary: Increment and decrement, Compare, Array index, These operations are all available, for example, with Pascal scalar types. I would welcome suggestions for getting the same effects with C enumeration types, other than the use of excessive casting to integer. Type casting to integer works, but destroys much of the program clarity that the enumeration type should have gained. ========================================================================== main () { enum col { red, blue, green, black }; enum col colvar; static char *colstrings[] = { "red", "blue", "green", "black" }; for (colvar = red; colvar <= black; colvar++) printf ("%s\n", colstrings[colvar]); } -- ps (Pat Shanahan) uucp : {decvax!ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ps arpa : sdcsvax!celerity!ps@nosc
merlyn@sequent.UUCP (04/18/84)
ps@celerity.UUCP says: > I have encountered a problem using enumerations with the 4.2bsd C compiler. > The System 5 C Programming Guide states that the current language treats > enumeration variables and constants as being of *int* type. There are > apparently no special constructs in the language for incrementing and > decrementing enumeration variables, and declaring arrays indexed by > enumeration types. ... and then goes on to demonstrate that the compiler chokes when attempting to use enums like Pascal enumerated types. The main problem here is the assumption that "enum"s are like Pascal's enumerated types. They aren't. They're a funny kluge that keeps you from having to ALWAYS do "#define FOO 1", "#define BAR 2", etc. to get a distinguished set of constants. They don't operate much different than that, in fact. The main problem with producing the things you asked about is that an enum type (unlike the similar Pascal construct) is not necessarily dense. For example, for the declaration: enum weekday { sun, mon, tue, wed = 100, thu, fri, sat } today, tomorrow; what would "today++" or "tomorrow = today + 1" mean if "today" was "tue"??? Also, how many elements are there in an array indexed by "weekday"? As you can quickly see, you don't really get much more support with enums than the (roughly) equivalent: typedef int weekday; #define sun 1 /* or is it 0? can't remember now! */ #define mon 2 #define tue 3 #define wed 100 #define thu 101 #define fri 102 #define sat 103 except that you don't have to say all those "#define"s and it's a bit easier to add and delete items. Comments? Randal L. ("(null)") Schwartz, esq. (merlyn@sequent.UUCP) (Official legendary sorcerer of the 1984 Summer Olympics) Sequent Computer Systems, Inc. (503)626-5700 UUCP: ...!XXX!sequent!merlyn where XXX is one of: cdi decwrl nsc ogcvax pur-ee rocks34 shell unisoft vax135 verdix
henry@utzoo.UUCP (Henry Spencer) (04/19/84)
C enumerations are much more restrictive than Pascal "scalar" types. The operations you are trying to do are indeed illegal. One can argue for weeks about whether this is a bug or a feature. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
davef@west44.UUCP (05/03/84)
It is not true to say that enums give you about the same level of support as a series of #define's: using define's your values will be treated as the integer constants they are but if you use enum's you will get all manner of stupid messages when you try to use (quite properly) relational operators on them. In order to make it possible for my students to use lint in conjunction with a package I has written I has to strip out all the enums and replace them with #defines. Such is progress! -- Dave Furber (west44!davef)