minow@decvax.UUCP (Martin Minow) (01/11/85)
break <label> failed to win widespread acceptance because
people couldn't agree where the label goes (anywhere, or
should it label the "proper" enclosing block, or what.
Goto, as noted, gives the necessary piece of information
and can serve as a visible warning that something special
is going on.
While scanning the source of a module done by one of
my collegues, I noticed a label at the start of a module.
"Why did you need a goto here?"
His reply was that he uses
label: ...
goto label;
to delimit an outer loop that goes on for several pages as
you can easily lose visual track of {...} nesting levels.
The moral is that goto is a perfectly valid addition to
a programmer's toolkit and that squeezing the last goto
out of a module may make it less maintainable even though
it improves the module's "structuredness".
Martin Minow
decvax!minowhenry@utzoo.UUCP (Henry Spencer) (01/13/85)
> While scanning the source of a module done by one of > my collegues, I noticed a label at the start of a module. > "Why did you need a goto here?" > > His reply was that he uses > > label: ... > goto label; > > to delimit an outer loop that goes on for several pages as > you can easily lose visual track of {...} nesting levels. The right comment on this is "why don't you split that loop body up into separate functions, as God clearly intended?" :-). If it's long enough to make tracking indenting levels difficult, it's too long to be in one monolithic piece. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
greenber@acf4.UUCP (ross m. greenberg) (01/14/85)
henry@utzoo.UUCP=> > If it's > long enough to make tracking indenting levels difficult, it's too > long to be in one monolithic piece. I disagree. If the piece of code is time critical or used ALOT, then the extra calls to subroutines might become too much overhead. There was a piece of code I had the misery to maintain a while back that had only about TWELVE levels of nesting. Try as I could I couldn't break it out into more efficient code, just easier to look at code. The ratio of ridiculous nesting level time to fun-to-look-at code was somewhere about 1.6:1, and I couldn't afford the extra time as this was a psuedo-realtime job. Of course, I did change tabbing to just a few spaces, so I didn't have to use two tubes :-) ------------------------------------------------------ Ross M. Greenberg @ NYU ----> { allegra,ihnp4 }!cmcl2!acf4!greenber <----
franka@hercules.UUCP (Frank Adrian) (01/15/85)
In article <4913@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> While scanning the source of a module done by one of >> my collegues, I noticed a label at the start of a module. >> "Why did you need a goto here?" >> >> His reply was that he uses >> >> label: ... >> goto label; >> >> to delimit an outer loop that goes on for several pages as >> you can easily lose visual track of {...} nesting levels. > >The right comment on this is "why don't you split that loop body >up into separate functions, as God clearly intended?" :-). If it's >long enough to make tracking indenting levels difficult, it's too >long to be in one monolithic piece. >-- Unfortunately, Henry, things aren't always that simple. If one is dealing with time critical or often used code within a loop, the overhead inccurred with all of the procedure calls can add up. I once shaved 30% execution time off a program by expanding a routine call in an often traversed loop. Funny, it didn't seem to make the program more readable. Well, I guess that's the breaks. The point is that sometimes execution speeds are critical and "good" coding style gets in the way of speed. That is unless you find me a C compiler which automatically does inline routine expansion. Now if you would have suggested using macros... "Rules are made to be broken..." Frank Adrian
guy@rlgvax.UUCP (Guy Harris) (01/18/85)
> The point is that sometimes execution speeds are critical and "good" coding > style gets in the way of speed. That is unless you find me a C > compiler which automatically does inline routine expansion. According to the C++ Reference Manual, the C++ compiler does do exactly that. It's a good idea, but the only other compiler I know about which does it is Xerox's Mesa compiler (I suspect there are others.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
henry@utzoo.UUCP (Henry Spencer) (01/19/85)
> Unfortunately, Henry, things aren't always that simple. If one is > dealing with time critical or often used code within a loop, the > overhead inccurred with all of the procedure calls can add up. > I once shaved 30% execution time off a program by expanding a routine > call in an often traversed loop. ... The point > is that sometimes execution speeds are critical and "good" coding > style gets in the way of speed. ... Agreed, unfortunately. But pragmatic perversions that are necessary about 0.1% of the time should not be held up for public acclaim as examples of recommended style. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry