Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!ragu!raymond
From: raymond@ragu.berkeley.edu (Raymond Chen)
Newsgroups: comp.lang.c
Subject: Re: Enumerated types... what's the point?
Keywords: enums
Message-ID: <1990Mar23.195004.4775@agate.berkeley.edu>
Date: 23 Mar 90 19:50:04 GMT
References: <1990Mar22.053148.10351@ncsuvx.ncsu.edu> <159@caslon.cs.arizona.edu> <8578@pt.cs.cmu.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: raymond@ragu.UUCP (Raymond Chen)
Distribution: usa
Organization: U.C. Berkeley
Lines: 35

Fred Christianson (flc@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@math.berkeley.edu     Maintainer of the csip Frequently Asked Questions