Goto (2007)

Post by ehutch79 » Thu, Oct 21, 2021, 7:32 PM UTC

blntechie wrote: post #105

bodyfour wrote: post #99

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

My first job was writing VB.NET code and it was hammered to us not to use GOTO. Once for a critical production bug, using GOTO was the quickest solution to fix and I used it with a comment to not fire me. And that code lived on for years.

Post by [deleted] » Thu, Oct 21, 2021, 7:35 PM UTC

0xffff2 wrote: post #112

bodyfour wrote: post #99

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

Can you give an example of where you've used goto in C or a C-like language? Or a rough estimate of the number of times you've found goto to be the best solution? I agree with your post in principle, but in practice I can't think of a single example where I've used a goto that wasn't eventually refactored to something better that didn't have the goto. Edit: Probably the most common example (and one given early in the…

Post by kazinator » Thu, Oct 21, 2021, 7:48 PM UTC

   int keypad() // returns 1 if correct key is entered, otherwise loops forever
   {
      keypad:
        switch (getkey()) {
        case 1:
          goto got_1;
        default:
          goto keypad;
        }

      got_1:
        switch (getkey()) {
        case 2:
          goto got_2;
        case 1:
          goto got_1;
        default:
          goto keypad;
        }

      got_2:
        switch (getkey()) {
        case 3:
          goto got_3;
        case 1:
          goto got_1;
        default:
          goto keypad;
        }

      got_3:
        switch (getkey()) {
        case 4:
          return 1;
        case 1:
          goto got_1;
        default:
          goto keypad;
        }
   }

   int got_1();
   int got_2();
   int got_3();

   int keypad()
   {
      switch (getkey()) {
      case 1:
        return got_1();
      default:
        return keypad();
      }
   }

   int got_1()
   {
     switch (getkey()) {
     case 1:
       return got_1();
     case 2:
       return got_2();
     default:
       return keypad();
     }
   }

   int got_2()
   {
      switch (getkey()) {
      case 3:
        return got_3();
      case 1:
        return got_1();
      default:
        return keypad();
      }
   }

   int got_3()
   {
      switch (getkey()) {
      case 4:
        return 1;
      case 1:
        return got_1();
      default:
        return keypad();
      }
   }

Post by Symmetry » Thu, Oct 21, 2021, 8:12 PM UTC

enriquto wrote: post #4

Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

Post by slaymaker1907 » Thu, Oct 21, 2021, 8:15 PM UTC

Jtsummers wrote: post #139

slaymaker1907 wrote: post #130

Earlier quoted context omitted.

I would disagree with defer being better than goto. Some people prefer it, but I think in a lot of ways it makes your control flow harder to see than just a few cleanup blocks at the end plus goto.

It's a tradeoff. defer in Go is more like a try/finally statement in other languages, there's a guarantee that the deferred code will run even when there's a panic in the intervening code: handler = open(something); defer close(handler); // something causing a panic Should be the same as: handler = open(something); try { // something causing an exception } finally { close(handler); } This is not necessarily true of g…