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.
comments?
ron
On Tue, 2 Sep 2003, ron minnich wrote:
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
--------------------------->PRE-PROCESSOR
into constant numbers.
error, sorry.
ron
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
enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE, COM2_DEVICE, COM1_DEVICE, SWC_DEVICE, MOUSE_DEVICE, KBC_DEVICE, GPIO_DEVICE, ACB_DEVICE, FSCM_DEVICE, WDT_DEVICE };
If you're going to stick with an enum, why not put a comma after the last entry, so diffs look cleaner later on:
enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE, COM2_DEVICE, COM1_DEVICE, SWC_DEVICE, MOUSE_DEVICE, KBC_DEVICE, GPIO_DEVICE, ACB_DEVICE, FSCM_DEVICE, WDT_DEVICE, };
Regards, Robert.
At 1:32 PM -0600 2/9/03, ron minnich wrote:
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.
comments?
ron
I think they work well when you have a sequence of numbers like this, but I would rather see each enum explicitly given it's value as in:
enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE=1, COM2_DEVICE=2, COM1_DEVICE=3, SWC_DEVICE=4, MOUSE_DEVICE=5, KBC_DEVICE=6, GPIO_DEVICE=7, ACB_DEVICE=8, FSCM_DEVICE=9, WDT_DEVICE=10 };
Otherwise you're forever trying to work out what the actual value is.
Where it doesn't work is when you have a bunch of random defines with unrelated values, or values that jump about all over the place.
Greg
On Tue, 2003-09-02 at 12:57, Greg Watson wrote:
I think they work well when you have a sequence of numbers like this, but I would rather see each enum explicitly given it's value as in:
enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE=1, COM2_DEVICE=2, COM1_DEVICE=3, SWC_DEVICE=4, MOUSE_DEVICE=5, KBC_DEVICE=6, GPIO_DEVICE=7, ACB_DEVICE=8, FSCM_DEVICE=9, WDT_DEVICE=10 };
Otherwise you're forever trying to work out what the actual value is.
More importantly, this style reduces the likelihood of screwing up the ABI by adding an enum member somewhere other than the end of the list.
<b
Greetings,
It seems to me that working out the integer value of an enum is actually abuse of the type. The closest one should get to that is ++ or -- to step through enumerated objects.
Of course, nobody ever takes liberties with that, especially me :-)
If the value itself is significant, it should probably be a define. If it's only significant for ABI compatibility, best practice is to only add to the end of the list and retain deprecated enums until an ABI breaking version change happens. A comma after the last enum value is a pretty decent invitation to do the right thing.
G'day, sjames
On Tue, 2 Sep 2003, Greg Watson wrote:
At 1:32 PM -0600 2/9/03, ron minnich wrote:
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.
comments?
ron
I think they work well when you have a sequence of numbers like this, but I would rather see each enum explicitly given it's value as in:
enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE=1, COM2_DEVICE=2, COM1_DEVICE=3, SWC_DEVICE=4, MOUSE_DEVICE=5, KBC_DEVICE=6, GPIO_DEVICE=7, ACB_DEVICE=8, FSCM_DEVICE=9, WDT_DEVICE=10 };
Otherwise you're forever trying to work out what the actual value is.
Where it doesn't work is when you have a bunch of random defines with unrelated values, or values that jump about all over the place.
Greg
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Wed, 3 Sep 2003, steven james wrote:
It seems to me that working out the integer value of an enum is actually abuse of the type. The closest one should get to that is ++ or -- to step through enumerated objects.
yeah but The Man Himself, Rob Pike, came up with this idea, and Ken and Dennis bless it. I figure if anybody can bless such a use of enum, the guy who invented the language is probably the one :-)
I'll try to get some Plan 9 excerpts for reference.
ron
-
Bryan O'Sullivan -
ebiederman＠lnxi.com -
Greg Watson -
Robert Walsh -
ron minnich -
steven james