Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site hercules.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!tektronix!teklds!hercules!franka
From: franka@hercules.UUCP (Frank Adrian)
Newsgroups: net.lang.c
Subject: Re: break and another use for goto's.
Message-ID: <379@hercules.UUCP>
Date: Tue, 15-Jan-85 10:44:49 EST
Article-I.D.: hercules.379
Posted: Tue Jan 15 10:44:49 1985
Date-Received: Fri, 18-Jan-85 02:15:34 EST
References: <7121@brl-tgr.ARPA> <23@decvax.UUCP> <4913@utzoo.UUCP>
Reply-To: franka@hercules.UUCP (Frank Adrian)
Organization: Tektronix, Beaverton OR
Lines: 30
Summary:
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