Perhaps my speculation on the broader issues of the computing problem was a misunderstanding particularly in view of the revelation by the original poster that they were really trying to make a point about the value of 'computed go to'.

However, am I wrong in suggesting that a 'computed go to' tests one variable or expression and then executes only one of the available clause options - depending on the outcome of that test (in a mutually exclusive option outcome) ?  (... a multiple test in the compiled code - I would hasten to point out.)

If that is the case, then 'if then else' is the appropriate direct replacement ... if one were really being sought (for the reasons incorrectly speculated.  I fail to see how that structure it is greatly more clumsy or harder to maintain than computed go to - and is more likely to guarantee indented clauses.

More importantly perhaps, would there be any speed impost beyond that of the original.

The subroutine thing was to take account of any commonality in the operations in each clause. OK, so a subroutine call is a resource overhead that you don't want so you repeat any code as necessary. This does not change the questions about 'computed go to'.

Incidentally, I use 'go to's at times - which seems to be more controversial in the computing world, and personally I have no particular axe to grind. Also I have no wish to revive a general debate on that issue - it has been done to death many times.

By all means use the 'computed go to' but what is the positive advantage ? 


Gary Hargraves
B.Eng (Civil); M.Eng.Sc. (Civil)



-----Original Message-----
From: Fortran 90 List [mailto:[log in to unmask]]On Behalf
Of Anthony Stone
Sent: Friday, 14 January 2005 8:12 PM
To: [log in to unmask]
Subject: Re: Computed GOTO


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.

Only Bertrand Meltz, in his latest posting, seems to have grasped the
point. Thanks!

At 11:02 on 14 January, Yasuki Arasaki wrote:

 > My guess is that the original code restarts an interrupted job,
 > with "index" holding how far the job has run so far (and saved on
 > disk between the chunks labeled 110, 109, ...)
 > etc

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.

At 10:22 on 14 January, Hargraves Gary wrote:

 > Having also had the benefit of a number of response postings, I
 > offer the following comments:
 >
 > *       Overall, the problem being addressed by the code might
 >         benefit from some broader restructuring (requiring more
 >         knowledge than currently conveyed)

Always a possibility, but not the point of my question.

 > *       It would appear on the evidence, however, that porting to
 >         standard compliant ... and not obsolescent ... code with as
 >         little trouble as possible is the object of the exercise

Not true either. I can convert it to standard-compliant code in
various ways with very little trouble. The point is quite simply that
the computed GOTO provides a straightforward way to do the job, and
the various compliant options all seem to me to be clumsier and less
transparent to the human reader. They also require the overhead of
additional tests, though that isn't a major issue.

 > *       For that reason, the 'if then ... else if ' type structure
 >         would be the one for the job - as only one successful test
 >         results in clause execution, and there is an option for a
 >         default clause ('else')

But it's cumbersome by comparison.

 > *       One might consider, of course, putting the most populous
 >         (likely) case first - if this is of assistance in improving
 >         overall speed

Irrelevant to this problem.

 > *       The very laudable suggestion of routine calls within each
 >         clause is supported - but falls into the category of dot
 >         point one above

This brings in the overhead of subroutine calls, and for an inner loop
is much worse than the extra tests needed for the simpler solutions.

--
Anthony Stone                           http://www-stone.ch.cam.ac.uk/
University Chemical Laboratory,         Email:   [log in to unmask]
Lensfield Road,                         Phone:  +44 1223 336375
Cambridge CB2 1EW                       Fax:    +44 1223 336362


************************************************************************
The information in this e-mail together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.
Any form of review, disclosure, modification, distribution
and/or publication of this e-mail message is prohibited.  
If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network.  
************************************************************************