Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!uwvax!oddjob!hao!noao!arizona!mike
From: mike@arizona.edu (Mike Coffin)
Newsgroups: comp.lang.c
Subject: Re: goto's in C: an opinion...
Message-ID: <1838@megaron.arizona.edu>
Date: Thu, 30-Jul-87 02:38:22 EDT
Article-I.D.: megaron.1838
Posted: Thu Jul 30 02:38:22 1987
Date-Received: Sat, 1-Aug-87 08:13:38 EDT
References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP> <765@haddock.ISC.COM> <1191@killer.UUCP> <1129@nu3b2.UUCP>
Reply-To: mike@megaron.arizona.edu.UUCP (Mike Coffin)
Organization: University of Arizona, Tucson
Lines: 28

In article <1129@nu3b2.UUCP> rwhite@nu3b2.UUCP (Robert C. White Jr.) writes:
> ...
>	Optimizing compilers can only optimize if they can group
>code statments and analize the possible execution paths.  By spotting
>obviously (needlessley) repetitive code and moving it outside the/a
>loop in question:

	[ example containing a while loop omitted ]

>
>	In this example the x+4 would be moved out of the loop to
>increase efficency.  If I did this loop with gotos, the compiler
>would not know where "out of the loop" was, so the calculation would
>be kept in every instance.  ...

This is incorrect.  It is not at all difficult for a compiler to
detect loops that are built from gotos instead of higher level
constructs.  Any decent compiler book has algorithms for doing it. In
fact, most optimizing compilers convert source code into some
intermediate form before reorganizing it; in the process of converting
to intermediate code the higher-level constructs (with the exception
of switch/case-like statements) are turned into ifs and gotos.

If you want to argue against gotos, I think you'll have to do it on
the basis of readability.

	mike coffin
	(mike@arizona.edu)