[comp.lang.c] Re^2: gotos

kimcm@ambush.UUCP (Kim Chr. Madsen) (04/20/88)

In article <225800022@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:

>I am FED UP with goto bashers! I'll admit that code filled with gotos
>may be messy: if I write a goto, it's because I feel like it! I don't
>give a DAMN whether you like goto's or not; I believe in using whatever 
>tool is at hand to get the job done. I frankly don't believe for
>ONE CLOCK TICK OF A CRAY 2 that gotos make code worse. Spaghetti is
>spaghetti, whether it is done with gotos or some other construct, and
>so is any other equivalent mess.

I'll agree wholeheartedly, the problem is though that in order to
propagate good coding style one has to be taught how to avoid gotos
when inappropriate -- especially if one comes from a BASIC
environment. This is best enforced by outlawing the use of goto's in
teaching structured programming - then after the student has learned
how to program structured you can teach them the uses of goto's (but I
bet the know it already). Unfortunately many computer students are
unable to leave the paradigm "GOTO'S CONSIDERED HARMFUL" behind them
once they got a grip on programming -- thus going to great lengths
(and pains) to write programs abandoning a "natural" goto.


Even Mr. Dijkstra had once compared the goto's with alcohol, it's nice
when used properly, you get headaches when you use it too much and you
don't give it to minors.


Regards 
Kim Chr. Madsen, AmbraSoft A/S, Rojelskaer 15, DK-2840 Holte (Denmark)
UUCP: kimcm@ambush.dk, PHONE: +45 2424 111, FAX: +45 2423 090

Though I am not naturally honest, I am so sometimes by chance.
					-- William Shakespeare
					

boyne@hplvly.HP.COM (Art Boyne) (04/20/88)

I would like to suggest a down-to-earth reason for having
goto's to all of you esoteric computer-science purists:

When faced with multiple occurances of a common section
of code, one has four choices (any others?):
  1) some sort of subroutine,
  2) replicating the code in multiple places,
  3) some type of big, ugly conditional statement to
     bring unite the occurances,
  4) goto.

Subroutine calls are SLOW -->sorry, but we real-world
types have performance constraints, and 68000's don't
come with 100 MHz options.

Replicating code fills ROM -->another constraint not
normally considered by those of you using VM systems.

My own personal opinion is that the conditional statement
may very well be uglier and harder to follow than a goto,
especially if there are a number of ways into the code, 
(eg., error handling).  Besides, the conditional statement
takes time to execute and fills ROM, a double-whammy.

So, what we have left is goto.  Before you flame back, I'm
not advocating the universal usage of goto, but there are
definitely times when it is the right answer to real problems.

As for the suggestion made in another response that assembler
be used - who ever claimed that assembler is more readable/
supportable than C even given gotos??!!

Art Boyne, !hplabs!hplvly!boyne

henry@utzoo.uucp (Henry Spencer) (04/24/88)

> When faced with multiple occurances of a common section
> of code, one has four choices (any others?):
>   1) some sort of subroutine,
>   2) replicating the code in multiple places,
>   3) some type of big, ugly conditional statement to
>      bring unite the occurances,
>   4) goto.

Remember that there are two separate issues here:  what you write, and the
code the compiler generates for it.  With modern compilers, the two are
often quite different.
-- 
"Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
non-negotiable."  --DMR              | {ihnp4,decvax,uunet!mnetor}!utzoo!henry

kelly@uxe.cso.uiuc.edu (04/25/88)

/* Written  8:40 pm  Apr 21, 1988 by friedl@vsi.UUCP in uxe.cso.uiuc.edu:comp.lang.c */
       ***********************************************
       * The problem is not with arrays but with the *
       * underlying thought that caused their use.   *
       *                                             *
       * The solution is not to ban the array but to *
       * teach the insight.                          *
       ***********************************************


       ***********************************************
       * The problem is not with the goto but with   *
       * the underlying thought that caused its use. *
       *                                             *
       * The solution is not to ban the goto but to  *
       * teach the insight.                          *
       ***********************************************
/* End of text from uxe.cso.uiuc.edu:comp.lang.c */

Very well said.

	Jim Kelly.
	kelly@solace.me.uiuc.edu

kimcm@ambush.UUCP (Kim Chr. Madsen) (04/26/88)

In article <408@dragos.UUCP> work@dragos.UUCP (Dragos Ruiu) writes:

>    Really, this is getting boring. Would all the goto fans please go get
>    themselves a BASIC compiler to write software and let us talk about
>    something else. :-)

(setq sarcastic-mode t)

Sure it is getting boring, but only because the goto-haters are so
unimaginative in their arguments. (-; Would all you goto-haters (and
purists) please stop bickering and write a Pascal-variant 103452/B
compiler leaving out the goto-construct and the repeat- and
for-statement (they are really just special cases of the while
construct (or is it the other way around)), or move this discussion to
talk.religion.

(setq sarcastic-mode nil)

Yes I do use gotos and yes I do use setq in lisp and I'm happy to do so!

Kim Chr. Madsen, AmbraSoft A/S, Rojelskaer 15, DK-2840 Holte (Denmark)
UUCP: kimcm@ambush.dk, PHONE: +45 2424 111, FAX: +45 2423 090

Though I am not naturally honest, I am so sometimes by chance.
					-- William Shakespeare