scs@adam.pika.mit.edu (Steve Summit) (07/15/89)
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, a good use for an if statement which always evaluates as false, and does nothing: if(0) ; #ifdef onething else if(Streq(command, "agitate")) agitate(); #endif #ifdef anotherthing else if(Streq(command, "blend")) blend(); #endif #ifdef yetanotherthing else if(Streq(command, "churn")) churn(); #endif else fprintf(stderr, "unknown command \"%s\"\n", command); The first, empty if keeps the code syntactically correct regardless of which of the "real" branches are #ifdeffed out. Steve Summit scs@adam.pika.mit.edu
john@frog.UUCP (John Woods) (07/18/89)
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...