[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: for loops
- From: Diego Fernandes Nehab <diego@...>
- Date: Sat, 01 Nov 1997 23:15:24 -0200
Alan Watson wrote:
> It is possible to argue that labelled breaks that break out of
> labelled blocks are more difficult to understand than gotos to
> labelled statements (and, let's face it, Java's break is just a goto
> hiding under a different name). The label in the goto and on the
> statement provides a stronger link between the place normal program
> flow is interupted and the place it resumes.
How so? It looks so simple to me, yet I can be wrong.
> > Dijkstra would like it better, for sure. :-)
> Perhaps, and perhaps not. This is not the 1970s, we are no longer
> programming in unstructured languages, and hopefully we are all a
> little wiser than we were then, perhaps even wise enough to use goto
> appropriately. (And by that I mean to break out of inner loops,
> perhaps once every few thousand lines.)
Ok, I couldn't resist making the joke. The ':-)' meant that. Besides, if
the discussion is on what Dijkstra would like or not, than I bet I'm
A friend of mine read something interesting in one of Linux's source
files near a goto statement. It said, in other words: "The hell with
Dijkstra! This way it is much more eficcient!". And he, the programmer,
is right, I think. As you said, we have to be wise to use goto
appropriately, and take benefit from it. But are we all? Haven't we all,
at least once, struggled to understand some nasty gotoed code written by
I think the best way to educate a programmer so that he feels that he
doesn't need goto statements is to cut it off the language, at first.
Then, when he knows he shouldn't use it often, he knows he doesn't need
it often, and he knows why, maybe he will be wise enough to use it.
But then, the message I wrote was an answer to two completely opposite
messages: someone didn't want break or continue at all, and someone else
wanted goto statements. I disagree with both, and wanted to express it.
I feel much better.