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