Gary Hargraves wrote:
>>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.)

Just to be fair, that isn't what the computed GOTO represents.
A computed GOTO represents the "table jump", whose use is obvious
in machine language but isn't directly available in many compiled
languages: Imagine an array holding statement labels, LABEL(N),
and what the computed GOTO does is, in effect, GOTO LABEL(INDEX).
So there really aren't any tests, just one subscript calculation
and a GOTO.

The structured programming paradigm doesn't have a direct equivalent
to it, but you are supposed to be able to write all your algorithms
using standard structures anyway, rendering GOTOs obsolete. For
handing exceptional cases that really doesn't fit into structured
logic, use of GOTOs is the more appropriate choice (as you say,
no need to be controversial about GOTOs). Well, that's the general
argument.

(Although the CASE construct doesn't always correspond to a table
jump, it's a generalization of it, and compilers are supposed to be
able to recognize and convert simple CASE constructs into table
jumps, as David LaFrance-Linden observed in his post, so usually
it is the appropriate replacement).

In this particular problem my impression was along the same lines
expressed by Werner Schulz's post, but if that has been considered,
then I can't think of another reason not to use computed GOTO, yet :-)
--
Yasuki Arasaki
[log in to unmask]