Anthony Stone wrote:
>What I thought was a simple question has sparked off some wild
>speculation that may distract attention from the real issue. I merely
>wish to enquire why it is thought necessary to remove a feature of the
>language that is the simplest solution to a particular kind of
>problem.
>
>
Of course the usual answer is that modern control structures
are better at doing what the computed goto was used for, but
you show a particular problem that seems not to be the case.
So what particular *kind* of problem is it? Can you give us a
rough idea as to what the code is doing? The given code seems
straightforward enough, but whether it is clear and natural
really depends on the problem. So forgive me for another wild
speculation as to what the problem is...
>Not at all. The code in question is in an inner loop. Depending on the
>value of index in a particular cycle of the loop, some of the code
>need not be executed.
>
>
Hmm, ..some of the code need not be executed, but each chunk is
strictly a subset of other chunks... Perhaps what you have is
a nested DO loop (perhaps with irregular bounds) flattened out:
DO L=1,NL
..L related stuff..
DO M=1,NM(L)
..M related stuff..
DO K=1,NK(L,M)
...
END DO
END DO
END DO
the loops might have been implemented as
DO I=1,N
GOTO (110,109,108,..), INDEX(I)
110 ..L related stuff.. (using L(I))
109 ..M related stuff.. (using M(I))
108 ... (using K(I))
END DO
the problem (if at all) with the latter approach is that you
must be very careful in ordering the data tables INDEX(*),
L(*), M(*),...
In this case (*if* this is indeed the case), the natural control
structure is the nested loop. Or perhaps this is not the case
and the original code is a good example of computed goto.
--
Yasuki Arasaki
[log in to unmask]
|