Path: utzoo!mnetor!uunet!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.lang.c
Subject: Re: gotos
Message-ID: <10324@steinmetz.ge.com>
Date: 8 Apr 88 14:08:26 GMT
References: <2571@cognos.UUCP> <77200029@uiucdcsp> <4307@ihlpf.ATT.COM> <2556@ttrdc.UUCP>
Reply-To: davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr)
Organization: General Electric CRD, Schenectady, NY
Lines: 26

In article <2556@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
> [...]
>I know this battle is an old chestnut, but for the record do you guys believe
>that superfluous flags and great big if-then statements are truly superior
>to the goto?  (And the break, which is a goto by another name.)  E.g.:

But... the break (and continue) are not the same as a goto. The goto
transfers control to a label, which may be anywhere in the program. The
break transfers control out of a loop.
	a) you know what it does when you write it
	b) you know what it does when you read it
	c) you won't move the stupid label or put code before it
	   which should be after.

I maintain that the evil is not the goto but the label. It can be put in
the wrong place to start, and often during program changes gets moved,
or statements inserted on the wrong side of it. I don't contend that
it's EVIL, just that it is inherently a higher overhead to write and
maintain then break and continue.

Yes, I have used a few gotos, but always examine the logic before I do
it. No, I don't think that longjmp() is a solution.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me