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