464,556 Members | 891 Online
Need help? Post your question and get tips & solutions from a community of 464,556 IT Pros & Developers. It's quick & easy.

# break to witch scope??

 P: n/a In <>I know the break in if wich is scoped in switch is break the switch,like: switch c case 1: if(b){ break; } ...... But like this: while(a){ if(b){ break; }//1 }//2 Does that break break witch scope? 1 or 2?? Nov 14 '05 #1
25 Replies

 P: n/a > In <>I know the break in if wich is scoped in switch is break the switch,like: switch c case 1: if(b){ break; } ..... But like this: while(a){ if(b){ break; }//1 }//2 Does that break break witch scope? 1 or 2?? A witch scope? Sounds like voodoo to me :) Anyway, it will escape the innermost "scope". Break will get you out of: switch / case for while do / while It will not have any effect on the if, so that it breaks out of the while-loop in you example. Good luck, -- Martijn http://www.sereneconcepts.nl Nov 14 '05 #2

 P: n/a On Fri, 18 Mar 2005 10:12:50 +0100, Martijn wrote: In <>I know the break in if wich is scoped in switch is break the switch,like: switch c case 1: if(b){ break; } ..... But like this: while(a){ if(b){ break; }//1 }//2 Does that break break witch scope? 1 or 2?? A witch scope? Sounds like voodoo to me :) It's used on a theodolite to search for gods, in conjunction with a thaumometer. Anyway, it will escape the innermost "scope". .... which is one of the following: Break will get you out of: switch / case for while do / while It will not have any effect on the if, so that it breaks out of the while-loop in you example. It wouldn't be much use if it only broke out of the 'if'... Chris C Nov 14 '05 #3

 P: n/a "chunhui_true" wrote in message In <>I know the break in if wich is scoped in switch is break the switch,like: switch c case 1: if(b){ break; } ..... But like this: while(a){ if(b){ break; }//1 }//2 Does that break break witch scope? 1 or 2?? "A break statement terminates execution of the smallest enclosing switch or iteration statement." Should be explained in any beginner C book... -- Tor Nov 14 '05 #4

 P: n/a In article , Tor Rustad wrote: ...."A break statement terminates execution of the smallest enclosing switchor iteration statement."Should be explained in any beginner C book... True. But note that this *is* an annoying feature of C that could easily be fixed. I have often wished that C had the "break n" feature of shell. Note, incidentally, that this is mentioned in the anti-C screed that was posted here recently (by some troll who found it on a web site). It was one of the (few) valid points made therein. Nov 14 '05 #5

 P: n/a "Kenny McCormack" wrote in message In article , Tor Rustad wrote: ..."A break statement terminates execution of the smallest enclosing switchor iteration statement."Should be explained in any beginner C book... True. But note that this *is* an annoying feature of C that could easily be fixed. I have often wished that C had the "break n" feature of shell. Never missed that myself. C provide 'goto' and 'longjmp' anyway. My attitude is to usually avoid them (and break/return) due to improved readability. The style of structured programming.. More annoying feature is that you need to put in all those break statements.. in switch (), to prevent fall-through. Note, incidentally, that this is mentioned in the anti-C screed that was posted here recently (by some troll who found it on a web site). It was one of the (few) valid points made therein. Why is "break n", more readable than "goto label"? -- Tor Nov 14 '05 #6

 P: n/a In article , Kenny McCormack wrote: True. But note that this *is* an annoying feature of C that could easilybe fixed. I have often wished that C had the "break n" feature of shell. Instead it has the much more readable labelled-break feature, which makes it easy to see exactly where execution will continue: while(1) { switch(x) { case 'q': goto loopend; ... } } loopend: ... -- Richard Nov 14 '05 #7

 P: n/a Kenny McCormack wrote: Tor Rustad wrote: ... "A break statement terminates execution of the smallest enclosing switch or iteration statement." Should be explained in any beginner C book... True. But note that this *is* an annoying feature of C that could easily be fixed. I have often wished that C had the "break n" feature of shell. Note, incidentally, that this is mentioned in the anti-C screed that was posted here recently (by some troll who found it on a web site). It was one of the (few) valid points made therein. So don't be a wuss. Use a goto. Works fine, is unambiguous. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson Nov 14 '05 #8

 P: n/a >In article ,Kenny McCormack wrote:... I have often wished that C had the "break n" feature of shell. In article Richard Tobin wrote:Instead it has the much more readable labelled-break feature, which makesit easy to see exactly where execution will continue: while(1) { switch(x) { case 'q': goto loopend; ... } } loopend: ... There are arguments for using "goto" here (and against "break n"); I consider at least some of them valid. But at the same time, there are arguments that go the other way. In particular, "goto" is largely unconstrained.[%] If one wants to argue for using goto here, one must explain why "for" and "while" loops are better than using goto: while (cond) { body; } vs: loop: if (!cond) goto end; body; goto loop; end: for instance. ----- [% C's "goto" is actually fairly well constrained, in that it can only jump within the current function. Pascal's "goto" can go anywhere in the entire program, jumping out of functions entirely; this is much worse. C has the same facility, of course, but spells it "longjmp".] ----- Of course, those with any sense of aesthetics immediately see why the "while" version is superior. :-) One of the arguments against constructs like "break 3" is that the target of the break becomes "unobvious" and/or moves if code is added. Those who make this argument must, however, explain why one level of "break" and/or "continue" is to be OK while N levels is not. There is a middle/compromise position, in which one has "labeled loops" and "continue loopname" and "break loopname" constructs. I have never seen one that I really liked, though. -- In-Real-Life: Chris Torek, Wind River Systems Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: forget about it http://web.torek.net/torek/index.html Reading email is like searching for food in the garbage, thanks to spammers. Nov 14 '05 #9

 P: n/a CBFalconer wrote: So don't be a wuss. Use a goto. Works fine, is unambiguous. Sure the goto works but I also come down on the side of the (possible future) extension: break N The main problem with the goto is that once labels are introduced the potential for typo's accidentally directing to the wrong label is also introduced. For instance, if code like: for(){ for(){ if(whatever)goto doneloop3; } } doneloop3: was replicated several times in one function and then modified slightly for different uses it is relatively easy to leave one of the exit goto's pointing to the wrong label. At least the compiler can catch cases where the label is duplicated, but it can't catch cases where the target is not as intended (but the label exists). The "break N" syntax is more robust under editing. For instance: for(){ for(){ if(whatever)break 2; } } can be replicated and no further editing is required - it is still valid. Nedit (and probably other editors) has a "find matching {}" command, this could be easily extended to "find break N }". Granted the goto target can be found now with a regular text search. The weakest part of the break N syntax that I see is that if an outer loop is eliminated the break N might then point to the wrong place. However if it then points to a nonexistant loop terminator the compiler could catch it. There is also the somewhat special case, which may not even be that great an idea, but: break outer; which would break to the _outermost_ loop structure. It is in many ways the complement of the existing break, which breaks to the innermost control structure. In smallish functions break [inner] and break outer should be sufficient for most needs. Of course if "break" is extended "continue" should also be modified to match. Regards, David Mathog ma****@caltech.edu Nov 14 '05 #10

 P: n/a ga*****@yin.interaccess.com (Kenny McCormack) writes: In article , Tor Rustad wrote: ..."A break statement terminates execution of the smallest enclosing switchor iteration statement."Should be explained in any beginner C book... True. But note that this *is* an annoying feature of C that could easily be fixed. I have often wished that C had the "break n" feature of shell. "break n" would be a maintenance nightmare. The *number* of levels to break is uninteresting; the important thing to know is *which* statement you want to break from. I'd love to see a labelled break (as in Ada, Perl, and other languages). Lacking that, we can make do with goto statements. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #11

 P: n/a Chris Torek wrote: .... snip ... There are arguments for using "goto" here (and against "break n"); I consider at least some of them valid. But at the same time, there are arguments that go the other way. In particular, "goto" is largely unconstrained.[%] If one wants to argue for using goto here, one must explain why "for" and "while" loops are better than using goto: while (cond) { body; } vs: loop: if (!cond) goto end; body; goto loop; end: It's more compact :-) -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson Nov 14 '05 #12

 P: n/a In article , Chris Torek wrote: C's "goto" is actually fairly well constrained, in that it canonly jump within the current function. Pascal's "goto" can goanywhere in the entire program, jumping out of functions entirely;this is much worse. C has the same facility, of course, but spellsit "longjmp". longjmp is fairly constrained too, just in entirely different ways than goto. (The fact that the constraints on longjmp don't include localizing its effect, though, makes it easier to horribly abuse than goto is.) Mind you, I think most people would also object to a nonlocal COME FROM, which is Rather Similar to what the constraints on setjmp/longjmp turn it into... dave -- Dave Vandervies dj******@csclub.uwaterloo.ca You know, you should never say something like "No one is expecting..." on Usenet. It is just too easy to disprove. The preferred form is "No one in his right mind is expecting..." --Stephan H.M.J. Houben in comp.lang.scheme Nov 14 '05 #13

 P: n/a On 18 Mar 2005 17:29:12 GMT, Chris Torek wrote: In article ,Kenny McCormack wrote:... I have often wished that C had the "break n" feature of shell.In article Richard Tobin wrote:Instead it has the much more readable labelled-break feature, which makesit easy to see exactly where execution will continue: while(1) { switch(x) { case 'q': goto loopend; ... } } loopend: ...There are arguments for using "goto" here (and against "break n");I consider at least some of them valid. But at the same time, thereare arguments that go the other way. In particular, "goto" islargely unconstrained.[%] If one wants to argue for using gotohere, one must explain why "for" and "while" loops are better thanusing goto: while (cond) { body; }vs: loop: if (!cond) goto end; body; goto loop; end:for instance. The micro optimization is goto test start: body; test: if (cond) goto start although this is what any decent compiler will produce for a while loop. -----[% C's "goto" is actually fairly well constrained, in that it canonly jump within the current function. Pascal's "goto" can goanywhere in the entire program, jumping out of functions entirely;this is much worse. C has the same facility, of course, but spellsit "longjmp".]-----Of course, those with any sense of aesthetics immediately see whythe "while" version is superior. :-)One of the arguments against constructs like "break 3" is that thetarget of the break becomes "unobvious" and/or moves if code isadded. Those who make this argument must, however, explain whyone level of "break" and/or "continue" is to be OK while N levelsis not. OTOH in C the determination of the continuation of even a single level break is not necessarily the simplest of tasks; multilevel breaks only compound the the problem. :-) One can argue that single level breaks and continues are part of the enclosing flow control construct whereas multilevel escapes are not. This may be a religious issue. There is a middle/compromise position, in which one has "labeledloops" and "continue loopname" and "break loopname" constructs.I have never seen one that I really liked, though. I prefer that alternative, albeit not in C (particularly since it is not available in C.) The problem I see is that there is no good place within C syntax for the label. Richard Harter, cr*@tiac.net http://home.tiac.net/~cri, http://www.varinoma.com All my life I wanted to be someone; I guess I should have been more specific. Nov 14 '05 #14

 P: n/a In article , Chris Torek wrote:If one wants to argue for using gotohere, one must explain why "for" and "while" loops are better thanusing goto: while (cond) { body; }vs: loop: if (!cond) goto end; body; goto loop; end: The same reason for preferring the goto over "break N" - it's more readable. One of the arguments against constructs like "break 3" is that thetarget of the break becomes "unobvious" and/or moves if code isadded. Those who make this argument must, however, explain whyone level of "break" and/or "continue" is to be OK while N levelsis not. Again, readability. For N > 1 the target is likely to be farther away. If it turns out not to be readable - perhaps because the block is very long - then it might even be clearer to use a goto, though I don't think I've ever done that. The "break N" syntax is particularly revolting - I haven't had to *count* anything in a programming language since Hollerith constants - and is of course fragile when a program is modified. There is a middle/compromise position, in which one has "labeledloops" and "continue loopname" and "break loopname" constructs.I have never seen one that I really liked, though. One obvious problem with most versions of this is that the name is at the wrong end of the block. A syntax that required the name at both end might aid readability - and catch some mistakes - but would be excessively verbose for C. I propose coloured brackets, with correspondingly coloured break statements. Obviously just a joke, but that didn't stop Python using indentation for block structure. -- Richard Nov 14 '05 #15

 P: n/a David Mathog wrote: CBFalconer wrote: So don't be a wuss. Use a goto. Works fine, is unambiguous. Sure the goto works but I also come down on the side of the (possible future) extension: break N How about (stop reading if your stomach is weak): break rand() % 42; ? (The management does not provide barf bags; you were warned.) -- Eric Sosman es*****@acm-dot-org.invalid Nov 14 '05 #16

 P: n/a In article , Eric Sosman wrote:David Mathog wrote: CBFalconer wrote: Sure the goto works but I also come down on the side of the (possible future) extension: break N How about (stop reading if your stomach is weak): break rand() % 42; I suspect that, in code where this would always be valid, those with weak stomachs wouldn't make it deep enough into the nesting to come across this particular bit of aesthetic displeasure. 'Twould provide greater opportunities for making autogenerated code Interesting, though. (The management does not provide barf bags; you were warned.) dave -- Dave Vandervies dj******@csclub.uwaterloo.ca The only rule is 'read everything Chris Torek writes'. Have you seen his latest shopping list? Heavy stuff... --CBFalconer and Richard Heathfield in comp.lang.c Nov 14 '05 #17

 P: n/a "Chris Torek" wrote in messageKenny McCormack wrote: ... I have often wished that C had the "break n" featureof shell. One of the arguments against constructs like "break 3" is that the target of the break becomes "unobvious" and/or moves if code is added. Those who make this argument must, however, explain why one level of "break" and/or "continue" is to be OK while N levels is not. The argument is really the same as -- why longjmp is worse than local jmp's (goto): That is, one level break is more readable than multi-level break... the longer the jmp is, the more difficult it's to follow control of flow for the human mind. break N smells somewhat like the arithmetic IF in FORTRAN. I will never ever forget the horrors of porting scientific programs written in a non-structured way. -- Tor Nov 14 '05 #18

 P: n/a In article , Eric Sosman wrote: .... Sure the goto works but I also come down on the side of the (possible future) extension: break N How about (stop reading if your stomach is weak): break rand() % 42;?(The management does not provide barf bags; you were warned.) heh. I will see that what I had in mind was the "constant-only" version. Nov 14 '05 #19

 P: n/a cr*@tiac.net (Richard Harter) writes: On 18 Mar 2005 17:29:12 GMT, Chris Torek wrote:There are arguments for using "goto" here (and against "break n");I consider at least some of them valid. But at the same time, thereare arguments that go the other way. In particular, "goto" islargely unconstrained.[%] If one wants to argue for using gotohere, one must explain why "for" and "while" loops are better thanusing goto: while (cond) { body; }vs: loop: if (!cond) goto end; body; goto loop; end:for instance. The micro optimization is goto test start: body; test: if (cond) goto start although this is what any decent compiler will produce for a while loop. A more usual form in optimizing compilers is if (! cond) goto next start: body; if (cond) goto start next: because it makes code motion out of the loop easier, and (I conjecture) because it helps performance due to better branch prediction. Nov 14 '05 #20

 P: n/a This is getting off topic, but what the heck... :-) In article Tim Rentsch wrote:A more usual [compiled] form [of a while loop] in optimizing compilers is if (! cond) goto next start: body; if (cond) goto start next:because it makes code motion out of the loop easier,and (I conjecture) because it helps performance dueto better branch prediction. Actually, this depends on both the compiler and the target. Some machines have simple branch-prediction hardware, and some have more complicated hardware. A machine that follows branches "for free" (using a separate branch unit and ALU) might as well use the multiple-goto version I gave as the simplistic expansion. For a machine whose hardware simply predicts "forward branch untaken, backward branch taken" might indeed want to use the above expansion. A machine whose hardware has branch prediction bits in the instruction could use various forms, and one that keeps dynamic branch prediction state could also use various forms. Examples of the first machine ("free" branches, at least in some cases) include UltraSPARC. Examples of the second (forward = untaken, backward = taken) include, I think, some Pentium variants, and pre-Ultra SPARC (and UltraSPARC when not using the new instructions). Examples of the third (prediction bits in branches) include UltraSPARC again, and examples of the fourth (dynamic in-CPU prediction) include other versions of Pentium. In some cases it is important to place the target of the branch at particular cache offsets (and/or make sure that the branch instruction is near but not at the end of a cache line). The micro-optimizations for some modern CPUs are quite tricky. -- In-Real-Life: Chris Torek, Wind River Systems Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: forget about it http://web.torek.net/torek/index.html Reading email is like searching for food in the garbage, thanks to spammers. Nov 14 '05 #21

 P: n/a Tim Rentsch wrote: cr*@tiac.net (Richard Harter) writes: On 18 Mar 2005 17:29:12 GMT, Chris Torek wrote:There are arguments for using "goto" here (and against "break n");I consider at least some of them valid.But at the same time, thereare arguments that go the other way. In particular, "goto" islargely unconstrained.[%] If one wants to argue for using gotohere, one must explain why "for" and "while" loops are better thanusing goto: while (cond) { body; }vs: loop: if (!cond) goto end; body; goto loop; end:for instance. The micro optimization is goto test start: body; test: if (cond) goto start although this is what any decent compiler will produce for a while loop. A more usual form in optimizing compilers is if (! cond) goto next start: body; if (cond) goto start next: because it makes code motion out of the loop easier, and (I conjecture) because it helps performance due to better branch prediction. The last way has two less jumps than the one before it, whenever a positive number of loops are executed. -- pete Nov 14 '05 #22

 P: n/a Chris Torek writes: This is getting off topic, but what the heck... :-) In article Tim Rentsch wrote:A more usual [compiled] form [of a while loop] in optimizing compilers is if (! cond) goto next start: body; if (cond) goto start next:because it makes code motion out of the loop easier,and (I conjecture) because it helps performance dueto better branch prediction. Actually, this depends on both the compiler and the target. [elaboration snipped] Right, I didn't mean to imply that this approach would necessarily be better on all platforms/implementations. Only that it often is. Having two independent branches where the prediction could be done separately usually will allow choices that are at least as good, and often better, than when there is only one. But you're absolutely right that there are other considerations, and those may end up being more significant. Nov 14 '05 #23

 P: n/a In message ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote: Instead it has the much more readable labelled-break feature, which makes it easy to see exactly where execution will continue: while(1) { switch(x) { case 'q': goto loopend; ... } } loopend: ... Another technique for achieving this particular effect: while (1) { switch(x) { case 'q': break; case 'a': ... continue; } break; } You just end each case with break or continue as appropriate. -- Kevin Bracey, Principal Software Engineer Tematic Ltd Tel: +44 (0) 1223 503464 182-190 Newmarket Road Fax: +44 (0) 1728 727430 Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/ Nov 14 '05 #24

 P: n/a On 2005-03-18 10:02, David Mathog wrote: CBFalconer wrote:So don't be a wuss. Use a goto. Works fine, is unambiguous. Sure the goto works but I also come down on the side of the (possible future) extension: break N [...] The "break N" syntax is more robust under editing. For instance: for(){ for(){ if(whatever)break 2; } } It looks nice until you refactor the code a bit and move the if inside a third loop or out of the second loop. Then you'll have to update all the break statements to the new structure of the code. A 'goto' would still work, even if moved up or down a nesting level. Nov 14 '05 #25

 P: n/a On 18 Mar 2005 17:29:12 GMT, Chris Torek wrote: [% C's "goto" is actually fairly well constrained, in that it can only jump within the current function. Pascal's "goto" can go anywhere in the entire program, jumping out of functions entirely; It can break out of nested subprograms* but only to a static (aka lexical) encloser/ancestor. Which is guaranteed to be active i.e. still on the stack. (* 'subprogram' covers both valued functions and nonvalued procedures, which Pascal distinguishes like some HLLs but not the C family. AFAIR Pascal doesn't actually use this term, but Fortran and Ada both do for the identical concept.) this is much worse. C has the same facility, of course, but spells it "longjmp".] Can break to any still-active activation, without any structural (nesting) relationship which C doesn't have anyway. Thus can't be checked in typical implementations, and such isn't required. In fact AIUI longjmp can sometimes be used for coroutines and (thus) cooperative tasking, although that is emphatically not standard. FWIW PL/I (as usual!) has both -- GOTO a constant label must be to a static (nested) encloser, but there are also (IME much less used and rightly so) label variables which identify a code-address in _any_ activation-frame which should still be active. Plus it _also_ has a form of throw-catch called (ON) CONDITIONs much like exceptions or signals in some other languages. - David.Thompson1 at worldnet.att.net Nov 14 '05 #26

### This discussion thread is closed

Replies have been disabled for this discussion.