Infinite for loops
-
Hello, love the show, long time listener, first time caller.
One of the company's c++ coding guidelines is that goto's are forbidden. For some developers who use goto statements as error handling this could present a problem. For others, ...
for ( ;; ) { // Some code for ( ;; ) { bool someError = func(); if (someError) { break; } // ... if (anotherError) { break; } // ... break; } // ... for ( ;; ) { // A few more hundred lines of code with more for( ;; ) loops. break; } // ... break; }After stumbling upon this beauty I searched and found over 200 infinite loops used as an error handling technique. Not one of these loops ever actually looped. -
Hello, love the show, long time listener, first time caller.
One of the company's c++ coding guidelines is that goto's are forbidden. For some developers who use goto statements as error handling this could present a problem. For others, ...
for ( ;; ) { // Some code for ( ;; ) { bool someError = func(); if (someError) { break; } // ... if (anotherError) { break; } // ... break; } // ... for ( ;; ) { // A few more hundred lines of code with more for( ;; ) loops. break; } // ... break; }After stumbling upon this beauty I searched and found over 200 infinite loops used as an error handling technique. Not one of these loops ever actually looped.Yep, seen it. I hate this irrational ban on goto. It's out of date - it dates from a time when decent control structures weren't common. A judicious, careful, occasional use of a goto is fine. Subverting a control structure to give it a different meaning is definitely not. For more, see Gotos Considered Harmful and Other Programmers' Taboos[^] [PDF, 17k].
Stability. What an interesting concept. -- Chris Maunder
-
Yep, seen it. I hate this irrational ban on goto. It's out of date - it dates from a time when decent control structures weren't common. A judicious, careful, occasional use of a goto is fine. Subverting a control structure to give it a different meaning is definitely not. For more, see Gotos Considered Harmful and Other Programmers' Taboos[^] [PDF, 17k].
Stability. What an interesting concept. -- Chris Maunder
Goto's are really really bad and should be super rarely used. They are not needed for error handling. The only good use I've seen for goto's is machine generated code with tools like YACC and LEX. Generally speaking, break, continue, and multiple returns can cause problems too. Readability and maintainability are very important. Imagine if you will a "come from" statement. You put a label X somewhere then in a totally different part of the method you place a "come from" label X. Whenever control reaches the label you goto the "come from". Imagine how hard it would be to read that code. What's wrong with using exceptions for error handling?
-
Goto's are really really bad and should be super rarely used. They are not needed for error handling. The only good use I've seen for goto's is machine generated code with tools like YACC and LEX. Generally speaking, break, continue, and multiple returns can cause problems too. Readability and maintainability are very important. Imagine if you will a "come from" statement. You put a label X somewhere then in a totally different part of the method you place a "come from" label X. Whenever control reaches the label you goto the "come from". Imagine how hard it would be to read that code. What's wrong with using exceptions for error handling?
RodgerB wrote:
Goto's are really really bad and should be super rarely used. They are not needed for error handling.
This
if (spin_trylock(&tty_lock.lock))
goto got_lock;
if (tsk == tty_lock.lock_owner) {
WARN_ON(!tty_lock.lock_count);
tty_lock.lock_count++;
return flags;
}
spin_lock(&tty_lock.lock);
got_lock:
WARN_ON(tty_lock.lock_owner);seems pretty well justified for me. You could do this with nested
ifs, but you would neither get more clarity nor faster code. Only code indenting out at your right screen margin.
Failure is not an option - it's built right in.
-
RodgerB wrote:
Goto's are really really bad and should be super rarely used. They are not needed for error handling.
This
if (spin_trylock(&tty_lock.lock))
goto got_lock;
if (tsk == tty_lock.lock_owner) {
WARN_ON(!tty_lock.lock_count);
tty_lock.lock_count++;
return flags;
}
spin_lock(&tty_lock.lock);
got_lock:
WARN_ON(tty_lock.lock_owner);seems pretty well justified for me. You could do this with nested
ifs, but you would neither get more clarity nor faster code. Only code indenting out at your right screen margin.
Failure is not an option - it's built right in.
I guess we could argue this back and forth. It comes down to avoiding mistakes and doing things as a matter of policy. E.g. I never do this: int* y, z; I always do this: int* y; int z; Why you ask. Too easy to read it wrong at a glance, too easy to miss something. Some logic as to why I never use goto's and why I don't put returns anywhere but at the very bottom or very top of a function. I believe this to be more than just a matter of style.
-
Yep, seen it. I hate this irrational ban on goto. It's out of date - it dates from a time when decent control structures weren't common. A judicious, careful, occasional use of a goto is fine. Subverting a control structure to give it a different meaning is definitely not. For more, see Gotos Considered Harmful and Other Programmers' Taboos[^] [PDF, 17k].
Stability. What an interesting concept. -- Chris Maunder
That is an excellent paper! I rarely use
goto, but sometimes it is the best solution to a problem. (Example: escaping from multiple nested loops.) I once read someone’s general rule that you always go forward, but I found one exception years ago:NEXT_BYTE:
if( x>xmin ) {
Byte = *(--vptr);
/* Skip whole bytes */
if( Byte == 0xFF ) {
x -= 8;
goto NEXT_BYTE;
}
}Sure the above code could be written using a loop and originally was, but this increased the speed (graphics code) enough to justify its use at the time.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra