Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.lang.c
Subject: Re: Is an argument to break, continue a bad idea?
Message-ID: <742@mwtech.UUCP>
Date: 2 May 90 08:50:46 GMT
References: <1990Apr25.180007.13243@cunixf.cc.columbia.edu> <591@atcmpe.atcmp.nl> <738@mwtech.UUCP> <1990Apr30.165059.1839@utzoo.uucp>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Followup-To: comp.lang.c
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 87

** First note that I try to move out this thread of "comp.std.c".
** Posters who followup please do also, this really doesn't any
** longer belong there.

In article <1990Apr30.165059.1839@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <738@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>>If the structure of your problem *demands* for this kind of
>>control flow, why not use a `goto'? ... [it's evil but] you reintroduce
>>it in the disguise of `break' and labeled `while'-statements.
>
>All control structures are gotos in disguise.  The point is that more
>constrained structures are easier for human beings to understand, even
>if the machine ends up translating them all into gotos anyway.  When
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 (that wasn't my point, but I think it's not your argument)     
>you see "break", you know it pops out of the current loop (or, sigh,

Suppose the following:

	..... {
		..... {
			..... {
				/*
				Here we are in some complicated nested
				conditions and loops. Suddenly something
				very ugly happens. Indeed, it's so ugly
				that we do not like to scatter error
				flags trhu some otherwise really clean
				algorithms. Finally we decide to "break"
				out. Unfortunately, the action we must
				take depends on the kind of error AND
				here is not the only place where these
				kinds of errors may happen.
				*/
				error_kind = ....;
				break;
			}
		}
	}
	switch (error_kind) {
	case NEVER_HAPPENS:
		.....
	case REALLY_NEVER_HAPPENS:
		.....
	case IF_THIS_EVER_HAPPENS_YOU_D_BE_BETTER_FAR_AWAY:
		.....
	}
}

To be honest, I'd rather use goto than the above. Furthermore as
programs tend to evolve with the time, it is probable that there is
only one kind of error in the beginning. If one new error conditions
arise, it will most probably be discernable by other informations. So
generally the above `error_kind'-variable will often not be added
in `goto-free' algorithms! If `the way to do it' was drawn by using
a goto, the `error-kind'-variable is not necessary at all and I
can much easier trace the "real" control flow in case of errors.
				
>switch in C).  When you see "goto", you don't know where it goes without
>hunting for the label, and you don't know if anything else goes to that
>label without searching the whole function for more gotos.  Humans are

Really?
What is your argument? If you wanted to say that `break' is preferable
over `goto', you must have a *very* advanced syntax directed editor.
With a normal editor (like "vi"), I'll have less problems to hunt for
`goto's (with labels!) than for `break'. If you recommend to avoid
`break' too, then what about the additional flags for breaking
out of loops. Don't they suffers from the same problems(%)? (I know of
what I write. When I was still a student, we were not allowed to use
`goto'. Later I wrote thousands and thousands of lines in a PASCAL dialect
that had `goto' not implemented!).

%: If the question is, from where may this or that point in a program
be reached, you are of course right. But if you must trace the control
flow for a given set of conditions and events, IMHO flags often obscure
things that would be clarified by DISCIPLINED USE OF `goto's. 

>not good at such searches; control structures that do not require them
>are easier to read.

Really not my experience but in general depends on how `goto's are used.
Well, I think we can ride this horse to dead giving examples and counter
examples ...

-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83