goto

why should i write:

while(faggot){
  ...
}
when it just gets turned into:

w1:
   if(faggot) goto w1e;
   ...
   goto w1;
w1e:
   ...

It's easier to read. That's pretty much the point of high-level languages like C.

I don't know, how about because:

1. It's shorter
2. It's more logical to read

>>2,3
Are you serious? The { } nesting bullshit is fucking obnoxious.

>>4
And to add the fact I can't use goto if the target address is inside one of those infinitely recursively kinky tangled jungles, makes me want to switch completely to asm.

>>4
CINP™¹
_________________________________________
1: Acronym for CINP Is not Python, C is Not Python is not Python.

No one said you had to use C.  Aside from the massive supportive community and endless libraries.

>>7
Yes, that's why I still use that bullshit.
Much like why I live on a rock orbiting a flaming ball of gas, it's not like I want to, it's because I have to.

>>8
Then shut yer gob. Use bindings for a different language or something. If it's for work, you're silly for complaining about having to do something you applied to do.

>>9
aww yeah gurl wanna suck my dick?

>>1
Because they're not the same. Loops can be split up, unrolled, or merged by the compiler as long as they perform as required by the C standard. They could use a fast compare-and-branch or increment/decrement-and-branch instructions, if possible, instead of setting flags or a condition register. if...goto hinders optimization and compile-time analysis and will make your code run slower in most, if not all, compilers. You also need to make sure there are no name conflicts in labels. That can easily become a jumbled mess of spaghetti code. If you have nested loops or move loops around, your system of w1:, w1e:, etc. labels could become unorganized. If you change the names, you might forget a label and have bugs without knowing why. C gives you looping constructs, so use them.

Note to all the faggots that use goto: it is a terrible programming practice, and the more you use it, the more you will fuck yourself.

>>12
Note to all faggots that use iteration: it is a terrible programming practice, and the more you use it, the more you will fuck yourself.

>>11-san, good job

　 ∧＿∧　　　∧＿∧　　　∧＿∧　　 ∧＿∧　 　 　　∧＿∧
　（　・∀・） 　 （　｀ー´）　　（　´∀｀）　 （　ﾟ ∀ﾟ ）　　　 （　＾∀＾）
　（　　　　つ┳∪━━∪━∪━━∪━∪━∪━┳⊂　 　 　つ
　｜ ｜　|　 ┃This thread has peacefully ended.┃　｜ ｜ ｜
　（_＿）＿） ┻━━━━━━━━━━━━━━┻　（_＿）＿）　　　　　Thank you.

　 ∧＿∧　　　∧＿∧　　　∧＿∧　　 ∧＿∧　 　 　　∧＿∧
　（　・∀・） 　 （　｀ー´）　　（　´∀｀）　 （　ﾟ ∀ﾟ ）　　　 （　＾∀＾）
　（　　　　つ┳∪━━∪━∪━━∪━∪━∪━┳⊂　 　 　つ
　｜ ｜　|　 ┃This thread has VIOLENTLY RISEN.┃　｜ ｜ ｜
　（_＿）＿） ┻━━━━━━━━━━━━━━┻　（_＿）＿）　　　　　FUCK you.

I'd like to take a moment to point out that >>1-san's code is wrong.  In fact, his two snippets are the exact opposite of each other.

>>16
everyone already noticed that, but no one other than you gave enough fucks to point it out.

isn't evolution great? It creates things out of nothing, and makes them automatically better! and on top of that, you dont hafta worry about it at all! it just works! AND IT'S NATURAL

>>17
ENOFUCKS

I only use gotos when I would otherwise use lots of flags. Like:


void fn(int* data, int iterations) {
  for(int iteration = 0; iteration < iterations; ++iteration) {
    for(x=0; x<W; ++x) {
      for(y=0; y<L; ++y) {
        if(iterationISdone(x,y,data)) goto done;
        ...
      }
    }
  done:
  }
}

Without gotos, this would likely be expressed as:


void fn(int* data, int iterations) {
  for(int iteration = 0; iteration < iterations; ++iteration) {
    int keepGOING = 1;
    for(x=0; keepGOING && x<W; ++x) {
      for(y=0; keepGOING && y<L; ++y) {
        if(iterationISdone(x,y,data)) {
          keepGOING = 0;
          break;
        }
        ...
      }
    }
  }
}

Although you could avoid gotos and flags by using a helper function, and returning from the helper function at an arbitrary point:


void performITERATION(int* data) {
  for(x=0; x<W; ++x) {
    for(y=0; y<L; ++y) {
      if(iterationISdone(x,y,data)) return;
      ...
    }
  }
}

void fn(int* data, int iterations) {
  for(int iteration = 0; iteration < iterations; ++iteration)
    performITERATION(data);
}