4 ms·

On the other hand, an unstructured program translated to a goto-less one via the introduction of lots of "flag" variables is just as hard to understand as the v

On the other hand, an unstructured program translated to a goto-less one via the introduction of lots of "flag" variables is just as hard to understand as the version using gotos. Thanks for this (also to the parent). I've just realised that goto has been so purged from my consciousness that my code is full of the 'flag' pattern. I haven't even considered goto as part of any language I've used in the last 20+ years. I guess I have some assumption-questioning to do.

ufo 12y ago
Replacing flags with break or return statements can often be a good way of making things a bit clearer (of course, this is a bit subjective). As a rule of thumb, gotos that jump forward are not as bad as gotos that jump backwards.
- mtdewcmu 12y ago
  You can get the same effect as goto without using the dreaded goto statement by combining a while loop and a large switch. Instead of 'goto nextstate', you just assign the state to the variable that controls the switch and fall through the loop one more time. A switch is basically syntactic sugar for a jump table.* This seems to be a fairly standard pattern when implementing, say, a virtual machine. * Of course, with optimization, the switch may turn into something completely different.
  - groovy2shoes 12y ago
    ufo had already mentioned this technique a couple levels up. Though it's equivalent, I think it's worse than just using gotos. Suddenly you have extra mutable state to worry about: the "next" state and a loop control variable. At that point, you've removed a layer of abstraction and introduced complexity. You've said "let the next state be foo, then repeat this loop, then if the next state is foo, then enter state foo" when you really meant: "go to state foo". goto in this case is practically declarative, insofar as a state machine diagram is declarative -- code structured in this way is a one-dimensional representation of the diagram.
    - nitrogen 12y ago
      A switch-based state machine can be as simple as something like this: enum { STATE0, STATE1, STATE2, STATE3 } state = STATE0; while(1) { switch(state) { case STATE0: if(input1) { state = STATE1; } else if(input2) { state = STATE2; } break; case STATE1: // etc. } }
      - groovy2shoes 12y ago
        break statements are goto statements with implicit labels! To really get rid of gotos, you'll need to have a loop control variable: ... int done = 0; while (!done) { ... done = 1; ... } Yes, it works fine and it's not terribly compelex. The version with goto is simpler because it's a more direct translation of the corresponding diagram.
        deleted 12y ago
        [deleted]
        dllthomas 12y ago
        Aren't loops and ifs goto statements with implicit labels?
        groovy2shoes 12y ago
        Heh, I suppose you're right :)
        mtdewcmu 12y ago
        If you want to find all the implicit gotos, just disassemble the compiled code. Your program will be littered with jmp instructions and the conditional versions of jmp. There's no getting away from them.
        12y ago

ufo 12y ago

Replacing flags with break or return statements can often be a good way of making things a bit clearer (of course, this is a bit subjective). As a rule of thumb, gotos that jump forward are not as bad as gotos that jump backwards.

mtdewcmu 12y ago
You can get the same effect as goto without using the dreaded goto statement by combining a while loop and a large switch. Instead of 'goto nextstate', you just assign the state to the variable that controls the switch and fall through the loop one more time. A switch is basically syntactic sugar for a jump table.* This seems to be a fairly standard pattern when implementing, say, a virtual machine. * Of course, with optimization, the switch may turn into something completely different.
- groovy2shoes 12y ago
  ufo had already mentioned this technique a couple levels up. Though it's equivalent, I think it's worse than just using gotos. Suddenly you have extra mutable state to worry about: the "next" state and a loop control variable. At that point, you've removed a layer of abstraction and introduced complexity. You've said "let the next state be foo, then repeat this loop, then if the next state is foo, then enter state foo" when you really meant: "go to state foo". goto in this case is practically declarative, insofar as a state machine diagram is declarative -- code structured in this way is a one-dimensional representation of the diagram.
  - nitrogen 12y ago
    A switch-based state machine can be as simple as something like this: enum { STATE0, STATE1, STATE2, STATE3 } state = STATE0; while(1) { switch(state) { case STATE0: if(input1) { state = STATE1; } else if(input2) { state = STATE2; } break; case STATE1: // etc. } }
    - groovy2shoes 12y ago
      break statements are goto statements with implicit labels! To really get rid of gotos, you'll need to have a loop control variable: ... int done = 0; while (!done) { ... done = 1; ... } Yes, it works fine and it's not terribly compelex. The version with goto is simpler because it's a more direct translation of the corresponding diagram.
      - deleted 12y ago
        [deleted]
      - dllthomas 12y ago
        Aren't loops and ifs goto statements with implicit labels?
        groovy2shoes 12y ago
        Heh, I suppose you're right :)
        mtdewcmu 12y ago
        If you want to find all the implicit gotos, just disassemble the compiled code. Your program will be littered with jmp instructions and the conditional versions of jmp. There's no getting away from them.
        12y ago