break to witch scope??

[chunhui_true]

In <<expert c>>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??

 

[Martijn]

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??

<troll>
A witch scope? Sounds like voodoo to me
</troll>

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,

 

[Chris Croughton]

<troll>
A witch scope? Sounds like voodoo to me
</troll>

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

 

[Tor Rustad]

In <<expert c>>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...

 

[Kenny McCormack]

"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.

 

[Tor Rustad]

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.. <g>

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"?

 

[Richard Tobin]

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.

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

 

[CBFalconer]

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.

 

[Chris Torek]

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:
...

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.

 

[David Mathog]

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
(e-mail address removed)

 

[Keith Thompson]

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.

 

[Dave Vandervies]

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".

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

 

[CBFalconer]

.... 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

 

[Richard Harter]

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:
...

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.

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 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.

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 "labeled
loops" 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, (e-mail address removed)
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.

 

[Richard Tobin]

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:

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 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.

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 "labeled
loops" 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

 

[Eric Sosman]

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.)

 

[Dave Vandervies]

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 (e-mail address removed)

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

 

[Tor Rustad]

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. <g>

 

[Kenny McCormack]

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.)[/QUOTE]

heh. I will see that what I had in mind was the "constant-only" version.

 

[Tim Rentsch]

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.

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.