 |
 |
Hargraves Gary 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.) > > 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. I don't understand your point in this context. SELECT/CASE is usually considered the appropriate replacement. IF-THEN-ELSE provides at most two cases without additional testing (of the same or some other variable or expression). The problem in question had several cases (I don't recall the total, but more than two). So, IF-THEN-ELSE would require additional work and additional code. As to guaranteeing indented clauses, I think the more important goal is to enhance legibility of the code. If that can be accomplished with properly indended control constructs, fine. But indentation is not the goal. If it becomes merely a fetish, it's counterproductive. Further, the issue was more complex in that some of the cases in the example, after a small amount of work, became instances of some other cases. So there was shared code in a particular pattern. > 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'. Well, it's overhead. But it's also not necessarily as legible. It's code duplication (the CALL statement) and the code actually performed is now no longer locally visible. Elimination of the CALLs by inlining the common code (the reverse direction of code development than is usually discussed in this situation) still leaves code duplicated - and this time it's maybe a substantial amount. The computed-goto solution with "fall-through" doesn't suffer any of these properties. Whether it's better is a decision best made by the programmer (which, in the particular case, is more legible and easier to verify correctness and to subsequently maintain?) I think computed- goto remains a reasonable choice in this kind of situation. -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare