cim2@pyuxv.UUCP (Robert L. Fair) (06/17/86)
Several folk seemed to have missed the point in my recent posting on
enums - A true enumerated type is a useful thing because it:
* catches lots of silly bugs with constant values, especially with
variables representing finite states in large applications.
* makes the code more readable & maintainable, especially in the
definitions section - all the possible value for a datatype are
gathered togther, and clearly marked:
enum { RUN, WAIT, SLEEP, READ, WRITE, SLUGS } state;
or
#define RUN 1
#define WAIT 2
#define SLEEP 3
#define READ 3
#define WRITE 5
#define SLUGS 6
int states;
(yes - there is a bug in the #defines...)
Unfortunatly those that be decided to do a STUPID, DUMB and
and CRETINOUS implementation of enums as integers (from those that
bring you unary+ ...)
As to the comment on printf not being able to print enums,
it can't print structures or unions either - so why worry!
Remember that enums are usually used to represent states or control flow
in a program - they aren't often printed out (except when debugging etc -
and for that you can always give a regular message:
enum { ALIVE, RUNNING, COLLAPSED } jogger;
...
if(jogger==ALIVE)
{
#ifdef DEBUG
printf("hey, he's alive\n");
#endif
...
}
or coerce to an int if need be.)
For more general cases, use C++ !
The only compiler I know which does enums right is Microsoft 3.0 for the IBM-PC.
Rob. Fair
Bell Communications Research
ihnp4!pyuxv!cim2jss@ulysses.UUCP (Jerry Schwarz) (06/17/86)
> > Unfortunatly those that be decided to do a STUPID, DUMB and > and CRETINOUS implementation of enums as integers (from those that > bring you unary+ ...) > Please, can't these discussions be carried out in a civil tone. Jerry Schwarz Bell Labs, MH P.S. The earliest compilers with enums at Bell Labs (around six or seven years ago) did treat each enum tag as a separate type. This seemed the natural and correct thing to do. People who began to use them complained about having to cast them to ints in many legitimate cases such as subsripts and comparisons. I personally remember being enthusiastic about them but giving them up and returning to #defines because of this. Enums are not a new feature in C (around here) and there is a large body of experience that favors the "enum as integral" definition.
friesen@psivax.UUCP (Stanley Friesen) (06/19/86)
In article <212@pyuxv.UUCP> cim2@pyuxv.UUCP writes: > >Unfortunatly those that be decided to do a STUPID, DUMB and >and CRETINOUS implementation of enums as integers (from those that >bring you unary+ ...) > As long as I can do a switch with efue cases!! Wat`gut t`asefues are adegst usedess fgr egst gf t`e pupgses A wgudd waft tg uset`ee& Adsg arraq anlmxino(jy(mnums would be *nice*, though declaring the array as haiving an enum index would be an acceptible requirement. > >The only compiler I know which does enums right is Microsoft 3.0 on the IBM-PC. Does it allow switches on enums?? If not, then it *isn't* right! -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ??
aglew@ccvaxa.UUCP (06/19/86)
In this discussion of enums, I thought I'd mention a quick and pleasant
tool. I don't know if it has been mentioned before - hell, I might have
mentioned it! but it is useful:
I get tired of seeing
#define MASK1 0x01
#define MASK2 0x02
#define MASK3 0x04
...
#define MASKN 0x8000000
and even the corresponding enum is a pain.
So, a filter that expands
enum_mask { MASK1, MASK2, MASK3 ... MASKN }
into the appropriate series of #defines or enums is useful.
Of course, I realize that this violates the type rule; or, rather, I need to
declare a type which is a Cartesian product of the masks. And that really
should be a struct. Unfortunately, many compilers are too dumb to recognize
that lots of tiny bit field operations in a struct really can be done with
a single logical operation. Too bad.
Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vmsrbj@icst-cmr (Root Boy Jim) (06/24/86)
I get tired of seeing
#define MASK1 0x01
#define MASK2 0x02
#define MASK3 0x04
...
#define MASKN 0x8000000
Me too. That is like a #define ONE 1, #define TWO 2, etc. Why not
#define MASK(x) (1 << (x)) /* or x-1 if you like */
and even the corresponding enum is a pain.
Or define the bit numbers as enums and generate masks from them.
enum bits { ox, ow, or, gx, gw, gr, ux, uw, ur, sticky, sgid, suid };
#define SUID MASK(suid); /* danger! */
So, a filter that expands
enum_mask { MASK1, MASK2, MASK3 ... MASKN }
into the appropriate series of #defines or enums is useful...
...Once in a blue moon.
Andy "Krazy" Glew. Gould CSD-Urbana. USEnet:
ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL
61801 ARPAnet: aglew@gswd-vms
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
...My vaseline is RUNNING...