Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c
Subject: Re: The final word on GOTO (Don't I wis
Summary: Not the same.
Message-ID: <1657@l.cc.purdue.edu>
Date: 13 Oct 89 13:26:52 GMT
References: <20324@<1989Sep14| <225800222@uxe.cso.uiuc.edu| <4208@cbnewsh.ATT.COM| <566@sunquest.UUCP<
Distribution: na
Organization: Purdue University Statistics Department
Lines: 54

In article <566@sunquest.UUCP>, ggg@sunquest.UUCP (Guy Greenwald) writes:
< In article <6490@ficc.uu.net|, peter@ficc.uu.net (Peter da Silva) writes:

			.....................
	
< | Really:
< | 	case whatever:
< | 		special-code...;
< | 		goto common;
< | 
< | Is a lot clearer than:
< | 	case whatever:
< | 		special-code...;
< | 		common(a, whole, bunch, of, random, arguments);
< | 		break;
< | -- 
< | Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation
< | Quote: Structured Programming is a discipline -- not a straitjacket.
> 
> If the arguments are really random, how can the function work? They
> can't just be chosen at random. As to their number, it depends on how
> many arguments the function needs. Regarding local variables, you know 
> very well that C can have external variables. I think that no one is going
> to win this argument against you because you're going to come up with
> contrived rebuttals no matter what anyone says. If goto's have a place
> in C, you haven't made a "case" for them.
> 
> /* Really: */
> 	case whatever:
> 		special-code...;
> 		goto common;
> /* Is no clearer than: */
> 	case whatever:
> 		special-code...;
> 		common();
> 		break;

One problem with the function call is that, as da Silva writes, there can
be a lot of other variables being used.  It can be quite difficult to manage
the implicit passage of arguments that Greenwald is assuming away.

There are other problems.  The cost of a subroutine call is necessarily
considerably greater than that of a transfer.  Furthermore, the first block
of code indicates that, at the termination of common, the program continues
from that point and does not do a return to the place from which it is called.
I find this rather a common situation, and have not seen an alternative to
the goto for this situation which is not horribly expensive and less clear.
Also, at the continuation, the "whole bunch of random arguments" is still
there for the rest of the program to use (or use as modified by common).
This is not provided for by a call.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)