Enumerated types... what's the point?

Raymond Chen raymond at ragu.berkeley.edu
Sat Mar 24 05:50:04 AEST 1990


Fred Christianson (flc at n.sp.cs.cmu.edu) proposed:
>#define a1	1
>#define a2	a1 + 1
>#define a3	a2 + 1
>...
>#define a100	a99 + 1

(Noting of course that we really should be parenthesizing the right-hand-sides.)

I wrote code like this back when I worried about porting to compilers
that didn't support enums.  It has the severe drawback that adding a
new symbol between two other symbols requires you to modify the line AFTER
the one you're inserting.

>#define a1	1
>#define a2	a1 + 1
>#define new     a2 + 1
>#define a3	new + 1		<--- see?
>...
>#define a100	a99 + 1

And it is a pain in the *** always having to go and modify lines that
ostensibly have nothing to do with what you're REALLY doing.  Especially
when the symbol you've added has a long name like COUNTERCLOCKWISE_ORIENTED,
so you have to type it twice and hope you don't misspell it the second time.
(And I assure you that forgetting to modify that subsequent line will
create bugs so absurdly subtle you'll wish you were bald.)

The enum method also makes the names of the symbols available to your debugger.

x(s)char*s;{*s&&(x(s+1),putchar(*s));}main(){x("\ndlrow ,olleh");}

(Oops, sorry, wrong newsgroup.)
--
raymond at math.berkeley.edu     Maintainer of the csip Frequently Asked Questions



More information about the Comp.lang.c mailing list