ron minnich rminnich@lanl.gov writes:
anybody object to anonymous enums? I've gotten used to them in Plan 9 and like them. Instead of this:
#define FLOPPY_DEVICE 0 #define PARALLEL_DEVICE 1 #define COM2_DEVICE 2 #define COM1_DEVICE 3 #define SWC_DEVICE 4 #define MOUSE_DEVICE 5 #define KBC_DEVICE 6 #define GPIO_DEVICE 7 #define ACB_DEVICE 8 #define FSCM_DEVICE 9 #define WDT_DEVICE 10
you get this: enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE, COM2_DEVICE, COM1_DEVICE, SWC_DEVICE, MOUSE_DEVICE, KBC_DEVICE, GPIO_DEVICE, ACB_DEVICE, FSCM_DEVICE, WDT_DEVICE };
The advantages I see
- somewhat less prone to error
- looks nicer
- the big one: enums are first-class objects to the compiler, and #defines are pertty much ripped out by the compiler and disappear into constant numbers.
I have no strong preference, but I am used to using defines. In this case as these numbers are magic constants not an enumeration, so I think an enumeration is much more likely to be error prone. Those are the logical device numbers on the superio chip, and they cannot.
Beyond which before I start using enums very much I want to get them implemented in romcc. Those and constant pointers are some of the last missing features, that can reasonably be added. After that I could look at compiling static.c with romcc....
The one thing I do get grumpy about are less then 8 space indents, so I would get: enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE, COM2_DEVICE, COM1_DEVICE, SWC_DEVICE, MOUSE_DEVICE, KBC_DEVICE, GPIO_DEVICE, ACB_DEVICE, FSCM_DEVICE, WDT_DEVICE };
It's pretty much a case of if you are going to use whitespace you might as well use enough of it that you can see.
For this case though I am pretty certain that enums are more error prone as the encourage the myth that you can change the value.
Eric