02-02-2005, 08:18 PM
I did make note of your optimization argument, above. Fortunately, I've never had the headache of writing a program that suffered from speed issues to the point that including a GOTO statement would significantly improve speed (but no other refactoring technique could). But then, I haven't written very many compound/nested loop/command-heavy programs. I've always found another way. So I'm not really qualified to comment on using GOTO for optimization.
As far as EXIT FOR: Technically, it transfers program flow ahead to the line immediately following the first NEXT command it encounters. So if you can stack your NEXT statements, you can EXIT FOR them as a block.
If you are processing commands in between your NEXT statements, then you obviously can't stack them, and therefore you can't EXIT them as a block. In this instance, I'd either:
1. Set the conditional variable in the inner-most loop, and have it calculate its way out, or
2. Block logically-related inner loops (ones with identical exitcondition) into a SUB, and call the SUB from the outer loop (which we don't want to kick out of). Then you can terminate the SUB to cease internal loops, and program flow will continue on with the outer loop.
*peace*
Meg.
As far as EXIT FOR: Technically, it transfers program flow ahead to the line immediately following the first NEXT command it encounters. So if you can stack your NEXT statements, you can EXIT FOR them as a block.
If you are processing commands in between your NEXT statements, then you obviously can't stack them, and therefore you can't EXIT them as a block. In this instance, I'd either:
1. Set the conditional variable in the inner-most loop, and have it calculate its way out, or
2. Block logically-related inner loops (ones with identical exitcondition) into a SUB, and call the SUB from the outer loop (which we don't want to kick out of). Then you can terminate the SUB to cease internal loops, and program flow will continue on with the outer loop.
*peace*
Meg.