gotos

Dave Burton daveb at laidbak.UUCP
Tue Apr 19 00:11:58 AEST 1988


In article <3470 at bunker.UUCP> garys at bunker.UUCP (Gary M. Samuelson) writes:
|In article <748 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
|>Here is a challenge to the denigrators of goto.
|Case 5:
|	b >>= g16;
|	m |= b;
|	x = *(--geom);
|	if (TEST) {	
|		if (ODD(x)) Case2();
|		else        Case1();
|	} else {
|		g4 = (x+1)/2;
|		if (ODD(x)) Case3();
|		else        Case4();
|	}

Gary - this is no flame in your direction (Herman deserves all he receives
for writing code like he challenged with). With the type of logic the
original code fragment was using, your modification would be deep down in
nested and re-nested function calls before you could say "Memory fault --
core dumped" :-).

About the only way (from the too little context given by Herman) that I know
to clean up his code without gotos is to use states. The overhead is very
small, typically just one extra test per 'loop'. Maybe something like:

enum calcs { start, state0, ..., state5 } state = start;
enum calcs compute();

switch (state) {
case start:
	state = compute();
	break;
case state0:
	x = 1+2;
	state = CRAP(x) ? state1 : state2;
	break;
...
case state5:
	b >>= g16;
	m |= b;
	x = *(--geom);
	if (TEST) {	
		state = ODD(x) ? state2 : state1;
	} else {
		g4 = (x+1)/2;
		state = ODD(x) ? state3 : state4;
	}
	break;
}
-- 
--------------------"Well, it looked good when I wrote it"---------------------
 Verbal: Dave Burton                        Net: ...!ihnp4!laidbak!daveb
 V-MAIL: (312) 505-9100 x325            USSnail: 1901 N. Naper Blvd.
#include <disclaimer.h>                          Naperville, IL  60540



More information about the Comp.lang.c mailing list