hmpfh, isn't there a newsgroup on goto somewhere out in the world?
I don't think there's any significant new contribution to that issue - it's
been discussed to death already, but maybe this aspect hasn't been looked at
a whole lot nevertheless:
In terms of expressive power, goto and all of the other control structures
are equivalent - in fact, the notion of "continuation" is the most generic,
allowing to abstract away not only goto, while, do and if (those are very
easy to identify as equivalent if you look at the generated assembly code)
but also recursion and iteration. Programming languages that provides
continuations as primitives (such as Scheme) don't really need anything else
(there is an if as a primitive in Scheme, but I think somebody has shown
that you don't really need it as long as there are continuation objects).
Thus, the discussion about "is goto bad or not" is not even academic. In my
experience coding in C, there is justification for goto in many cases if the
underlying OS does not support structured exception handling - for example,
if within a function body, there are several error exits in which you need
to clean up resources to various degrees - without SEH and goto, you would
need to repeat code in several places, thus obstructing code and introducing
many subtle cases of errors.
Quote:> Today's development favors "no goto", and I think the reason it came
> about is :
> ---------------------------------------------------
> Many years ago, the main programming languages were COBOL, FORTRAN. At
that
> time, "if" statement was very simple, e.g. in Fortran, the if-statement is
> if (....) goto ....
> Hence people must use lots of "goto". This, coupled with the fact that
> labels do not have to be consecutive, (FORTRAN) e.g.
> 1000 .....
> if (....) goto 20
> 700 .......
> .......
> if (....) goto 300
> ......
> 5000 ......
> .....
> 60 .....
> ...............
> people really had a difficult time to trace programs.
> Some computer scientists found that, if we introduce constructs like
(Qbasic
> constructs)
> while ... wend
> do .... loop while ....
> do .... loop until ....
> do while ..... loop
> do until ..... loop
> select case .... end select
> we can do away with "goto", hence goes the confusion as well.
> But now one has to learn a lot of constructs, instead of learning one
simple
> "goto".
> Was the situation really that bad in the old times? Not so. Programmers
have
> long discovered some "good programming habits". Consider the following
piece
> of (FORTRAN) code :
> if ( .not. condition1) goto 200
> ......
> ......
> ......
> goto 1000
> 200 if ( .not. condition2) goto 400
> ......
> ......
> ......
> goto 1000
> 400 if ( .not. condition3) goto 600
> ......
> ......
> ......
> goto 1000
> 600 if ( .not. condition4) goto 800
> ......
> ......
> ......
> goto 1000
> 800 if ( .not. condition5) goto 1000
> ......
> ......
> 1000 .........
> Moreover, labels are strictly in ascending order. As you can see, the
above
> coding is very clear in its intent, and, in my opinion, is in fact much
> better than the "no goto" but levels upon levels of nested "if" statements
> common nowadays.
> Now people introduce something like "break LABEL" or "break No-of-levels"
> ....
> Why not use the "goto" instead?