Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!usc!csun!fedeva!premise!mirror!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.lang.c
Subject: Re: null if statements
Message-ID: <1639@frog.UUCP>
Date: 17 Jul 89 22:08:00 GMT
References: <713@srhqla.SR.COM> <12685@bloom-beacon.MIT.EDU>
Organization: Misanthropes-R-Us
Lines: 38

In article <12685@bloom-beacon.MIT.EDU>, scs@adam.pika.mit.edu (Steve Summit) writes:
> in article <713@srhqla.SR.COM>, tcm@srhqla.SR.COM (Tim Meighan) writes:
> > 1. There is rarely, if ever, a case when it would be reasonable for a
> >    program to contain an if() statement that, when evaluated as true,
> >    does absolutely nothing.  (In other words, simply fall through to
> >    the code to be executed when the if() is false.)
> Just yesterday I discovered, to my considerable astonishment,
> 	if(0)
> 		;
> #ifdef onething
> 	else if(Streq(command, "agitate"))
> 		agitate();
> #endif
	...
> #endif
> 	else	fprintf(stderr, "unknown command \"%s\"\n", command);
> 
Uh, how about

#ifdef this
	if (Streq(command, "spin")) spin();
	else
#endif
#ifdef  that
	if (Streq(command, "wash")) wash();
	else
#endif
	fprintf(stderr, "unknown command \"%s\"\n", command);

I *think* the example was someone trying to be too clever, or possibly not
being clever enough.  Even if the compiler optimizes the null if() out, it
still doesn't "say what you mean".  (or was this automatically generated code
that got separated from the generator?)
-- 
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
    People...How you gonna FIGURE 'em?
    Don't bother, S.L.--Just stand back and enjoy the EVOLUTIONARY PROCESS...