Re: goto... is it so bad?
Walter Bright <walter@digitalmars-nospamm.com> wrote:
Daniel T. wrote:
For example, put your finger at the point where the comment "rest
of the program" is and ask yourself what code was executed before
that point. In the latter example, one need only know what the
value of tmp, b, and a are (or would be if it still existed in the
case of tmp,) in order to know exactly what has transpired. In the
former case you cannot reconstitute the execution path. Maybe
foo() returned true, maybe the loop naturally fell out, or maybe
the entire while loop was skipped due to some other goto above it
that went to the out_a label. In using the goto, you have lost the
"progress of the process" as Dijkstra points out in his paper.
Yet I see the problem as I failed to grasp the goto-less logic. I
understood the goto one perfectly.
Let me try again to explain Dijkstra's paper (As I understand it at
least. :-)
[bringing back the examples]
while(a) {
while(b) {
if(foo())
goto out_a; // exit the outer loop
}
// more code
}
out_a:
// rest of the program
becomes:
bool tmp = false;
while(true){
while(b && !(tmp = (foo() != 0))){
// code which might change the
// truth value of something
}
if(tmp or not a) break;
// more code
}
// rest of the program
OK, let's pretend we run the code fragments in a debugger with a
break-point at the line immediately after the comment "rest of the
program". What was the last line executed? You have a list of variable
values and the stack pointer...
With the goto version, you *cannot* know unless you were methodically
stepping through the fragment. With the goto-less version, you can
simply look at the values of the variables and know.
... our intellectual powers are rather geared to master static
relations and that our powers to visualize processes evolving in time
are relatively poorly developed. For that reason we should do (as
wise programmers aware of our limitations) our utmost to shorten the
conceptual gap between the static program and the dynamic process, to
make the correspondence between the program (spread out in text
space) and the process (spread out in time) as trivial as possible.
Goto can make that correspondence between program and process more
complex.
I see a caveat to his paper however. Dijkstra was referring to a goto
command that could jump anywhere in the program whereas in C/C++ the
goto is localized to only its own function. This mitigates the problem
quite a bit and it *is* possible to write goto code in C that does not
increase the number of textual indexes needed to understand the process.
Your example however is not such.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]