ron minnich <[EMAIL PROTECTED]> 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
_______________________________________________
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
