Hi,
I'm using the uVision Realview compiler and am confused about the 'break' statement inside the 'while' loop inside the 'case' statement : does it exit the while loop and executes the 'extra code' or does it exit also the 'case' statement completely without executing the 'extra code'?
use next (abstract) code:
switch ( x ) { case y: while(1){ break; } 'extra code' break; }
Thanks
Henk
The break is owned by the closest surrounding statement that supports break - in this case the while, so it doesn't affect the behaviour of the switch statement.
Note the funny thing with continue, which is only supported by loops, but not by a switch statement:
for (;;) { switch (xx) { case 0: break; // exits switch statement, continues last statements in loop. case 1: continue; // all the way to restart the for loop. } // more statements to process before next iteration of loop if (y) { break; // exit loop } }
The break exits the while loop only.
If you want to skip the 'extra code' in addition to exiting the while loop, you can use and test a boolean variable after the while loop that indicates whether the while loop was exited regularly (if it's not an infinite loop like in the example) or by hitting a break statement.
As long as you don't believe that there's no good use whatsoever for a goto statement, breaking out of deeply nested control structures is one of the few places where a goto would be useful.
Some languages have extended "break" to specify how many nestings to break out of, just to avoid people having to either add a goto or introduce extra state variables that can be very hard to keep track of.
the GOTO fear is somewhat justified simply because the GOTO fear is so prevalent that I would anticipate that it is one of the least tested features of any compiler.
I use about one GOTO per year and every time make absolutely sure that a) the compiler version for this will not change b) that the compiler does process it correctly
If you want to skip the 'extra code' in addition to exiting the while loop, you can use and test a boolean variable after the while loop that indicates whether the while loop was exited regularly is a typical example of the ridiculous workaronnds one must use to avoid using the much maligned GOTO
NO, I would never accept a piece of code with GOTOs liberally strewn all over the place (read made by an assembler programmer that has not grasped C yet) but a judicially considered use of a GOTO is, sometimes, just the right thing.
Another example of jumping through hoops to make "REAL C" is the "no global variables" rule. I once worked on a huge ARM project where the rule was in effect. Instead there was a, I guess the largest I have ever seen, structure in main() a pointer to which was carried all over the place. "no global variables", with everythijg in that structure, in effect, being global what a joke.
Erik
If really goto, it's almost always a question of a forward goto to jump many steps out of something. Much, much better to have loop constructs to get back to an earlier position to repeat something.
No globals - something only a dimwitted person may think about. The rule is to keep down the number of symbols in each available namespace. But hardly any non-trivial program can manage with zero globals since most programs are expected to produce some side effect and you normally needs to keep track of some state to do that.
So with a little brain, the project management - or developer(s) - should have understood that they should keep down the number of auto variables in a single function, and the number of members of a struct. It's almost a question of minimizing the sum of the squares by making sure that n never gets really big anywhere in the program.
A professional developer shouldn't just follow rules, but should understand the reasons behind rules, and constantly work to change the rules until they are more advantageous.