ok@quintus.UUCP (Richard A. O'Keefe) (03/08/88)
In article <25348@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes: > Currently I average about one goto per 10,000 lines of code, all of them > being transfers to a procedure epilog, e.g > > foobaz() { > .... > allocate space and other setup > .... > if (some_special_condition) goto wrapup; > .... > wrapup: > deallocate space and other cleanup > } > > But do people actually use it to any signifigant extent? Why not just > drop it? > -- I very often write code of the form sometype foo() { int state = 0; <side effect 1> /* open file, or allocate memory */ state = 1; <side effect 2> /* same sort of thing */ ... state = N; <return new object> ERROR: switch (state) { case N: /* undo side effect N */ /* falls through to */ case N-1: ... case 1: /* undo side effect 1 */ case 0: /* return error code */ } } If you are trying to write code that other people can use, it really isn't good manners to lose chunks of memory just because you couldn't open a file. One of these per library package, and one per program, doesn't seem excessive. This is a sufficiently stylised approach that it could be replaced by some other mechanism. (Nested exception handlers? C++ destructors? unwind-protect?) But in a language like C, why not just keep the goto? {Actually, a break-from-labelled-statement would work too, but that's just another goto.} There's another reason for retaining the goto. Look at the output of YACC some time. I counted five labels in yyparse(), but may have missed some. It isn't just people who write C, you know! Why shouldn't people be allowed to write compilers which generate C?
g-rh@cca.CCA.COM (Richard Harter) (03/08/88)
In article <740@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >I very often write code of the form > [Elegant stylised error handling mechanism example deleted.] Pretty. I am going to have to think about that. >If you are trying to write code that other people can use, >it really isn't good manners to lose chunks of memory just >because you couldn't open a file. One of these per library >package, and one per program, doesn't seem excessive. Not good manners is a weak term -- particularly in code which is designed to run as a background process indefinitely. The inadequacies of malloc and C memory allocation is a topic for another time. >This is a sufficiently stylised approach that it could be replaced by >some other mechanism. (Nested exception handlers? C++ destructors? >unwind-protect?) But in a language like C, why not just keep the goto? >{Actually, a break-from-labelled-statement would work too, but that's >just another goto.} Not really. The model for break-from-labelled-statement is a stack of return points, a generalization of the procedure return point stack. With such a command you can only goto a point in the stack; you are just going up several levels instead of one. With a real goto you can transfer to a point which is not in the stack. [And, yes, I know that you can simulate goto's with a breaks. You can program recursion in Fortran too.] As to your general point. Without some sort of mechanism for error handling escapes, one needs a goto to build it by hand. C has a goto, it doesn't have generalized escapes, and that's the way it is. It would be awkward to simply delete the goto from C, to say nothing of breaking a lot of existing code. [Whether this code should have been written that way is another matter.] I am still not convinced that the goto should be retained in a successor language (e.g. D) -- it does seem to me that one could have a more structured mechanism such as the break-from-labelled-statement and dispense with goto's entirely. >There's another reason for retaining the goto. Look at the output of >YACC some time. I counted five labels in yyparse(), but may have >missed some. It isn't just people who write C, you know! Why shouldn't >people be allowed to write compilers which generate C? This may be a good argument, which I will pass onto those who are better acquainted with the problems of writing programs which write programs. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.