martin@mwtech.UUCP (Martin Weitzel) (05/02/90)
** First note that I try to move out this thread of "comp.std.c". ** Posters who followup please do also, this really doesn't any ** longer belong there. In article <1990Apr30.165059.1839@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <738@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >>If the structure of your problem *demands* for this kind of >>control flow, why not use a `goto'? ... [it's evil but] you reintroduce >>it in the disguise of `break' and labeled `while'-statements. > >All control structures are gotos in disguise. The point is that more >constrained structures are easier for human beings to understand, even >if the machine ends up translating them all into gotos anyway. When ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (that wasn't my point, but I think it's not your argument) >you see "break", you know it pops out of the current loop (or, sigh, Suppose the following: ..... { ..... { ..... { /* Here we are in some complicated nested conditions and loops. Suddenly something very ugly happens. Indeed, it's so ugly that we do not like to scatter error flags trhu some otherwise really clean algorithms. Finally we decide to "break" out. Unfortunately, the action we must take depends on the kind of error AND here is not the only place where these kinds of errors may happen. */ error_kind = ....; break; } } } switch (error_kind) { case NEVER_HAPPENS: ..... case REALLY_NEVER_HAPPENS: ..... case IF_THIS_EVER_HAPPENS_YOU_D_BE_BETTER_FAR_AWAY: ..... } } To be honest, I'd rather use goto than the above. Furthermore as programs tend to evolve with the time, it is probable that there is only one kind of error in the beginning. If one new error conditions arise, it will most probably be discernable by other informations. So generally the above `error_kind'-variable will often not be added in `goto-free' algorithms! If `the way to do it' was drawn by using a goto, the `error-kind'-variable is not necessary at all and I can much easier trace the "real" control flow in case of errors. >switch in C). When you see "goto", you don't know where it goes without >hunting for the label, and you don't know if anything else goes to that >label without searching the whole function for more gotos. Humans are Really? What is your argument? If you wanted to say that `break' is preferable over `goto', you must have a *very* advanced syntax directed editor. With a normal editor (like "vi"), I'll have less problems to hunt for `goto's (with labels!) than for `break'. If you recommend to avoid `break' too, then what about the additional flags for breaking out of loops. Don't they suffers from the same problems(%)? (I know of what I write. When I was still a student, we were not allowed to use `goto'. Later I wrote thousands and thousands of lines in a PASCAL dialect that had `goto' not implemented!). %: If the question is, from where may this or that point in a program be reached, you are of course right. But if you must trace the control flow for a given set of conditions and events, IMHO flags often obscure things that would be clarified by DISCIPLINED USE OF `goto's. >not good at such searches; control structures that do not require them >are easier to read. Really not my experience but in general depends on how `goto's are used. Well, I think we can ride this horse to dead giving examples and counter examples ... -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
henry@utzoo.uucp (Henry Spencer) (05/04/90)
[Puzzled comp.lang.c readers, note that this has moved over from comp.std.c.] In article <742@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: > ..... { > ..... { > ..... { > /* > Here we are in some complicated nested > conditions and loops. Suddenly something > very ugly happens... Diagnosis: excessively nested control structures. The remedy is to re-read K&R1 chapter 4 about the most important control structure of all: functions. In 15 years of active C programming, I don't think I have ever used a goto in original code. (Once or twice I have used one in maintaining code that was already full of them, when I didn't have time to redo it.) I attribute this mostly to a strong distaste for deep nesting. Breaking things up into functions makes life easier in a lot of ways, not least of them being the ability to use `return' to get yourself out of messes. Amazingly enough, when you do this systematically, you find that you seldom have any desire to use `goto'. It just isn't needed. >>... When you see "goto", you don't know where it goes without >>hunting for the label, and you don't know if anything else goes to that >>label without searching the whole function for more gotos... > >Really? >What is your argument? If you wanted to say that `break' is preferable >over `goto', you must have a *very* advanced syntax directed editor. >With a normal editor (like "vi"), I'll have less problems to hunt for >`goto's (with labels!) than for `break'... I don't care much for `break' either, although I concede its necessity in some cases because C lacks higher-level constructs to do certain jobs. Mind tend to come with comments like `/* NOTE BREAK OUT */' to make them more conspicuous. >If you recommend to avoid >`break' too, then what about the additional flags for breaking >out of loops. Don't they suffers from the same problems(%)? ... I recommend composing programs in an orderly way to avoid the need, mostly. >... IMHO flags often obscure >things that would be clarified by DISCIPLINED USE OF `goto's. Yes, it's better to simply avoid both. -- If OSI is the answer, what is | Henry Spencer at U of Toronto Zoology the question?? -Rolf Nordhagen| uunet!attcan!utzoo!henry henry@zoo.toronto.edu