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]

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

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

--
Martijn
http://www.sereneconcepts.nl

[Chris Croughton]

On Fri, 18 Mar 2005 10:12:50 +0100, Martijn
<su*********************@hot-remove-mail.com> wrote:

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

"chunhui_true" <ch*********@gmail.com> wrote in message

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

--
Tor <torust AT online DOT no>

[Kenny McCormack]

In article <Pd******************@news4.e.nsc.no>,
Tor Rustad <to****@online.no.spam> 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.

[Tor Rustad]

"Kenny McCormack" <ga*****@yin.interaccess.com> wrote in message

In article <Pd******************@news4.e.nsc.no>,
Tor Rustad <to****@online.no.spam> 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.. <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"?

--
Tor <torust AT online DOT no>

[Richard Tobin]

In article <d1**********@yin.interaccess.com>,
Kenny McCormack <ga*****@interaccess.com> wrote:

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]

Kenny McCormack wrote:

Tor Rustad <to****@online.no.spam> 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

[Chris Torek]

>In article <d1**********@yin.interaccess.com>,

Kenny McCormack <ga*****@interaccess.com> wrote:

... I have often wished that C had the "break n" feature of shell.

In article <d1**********@pc-news.cogsci.ed.ac.uk>
Richard Tobin <ri*****@cogsci.ed.ac.uk> 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:
...

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) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[David Mathog]

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

[Keith Thompson]

ga*****@yin.interaccess.com (Kenny McCormack) writes:

In article <Pd******************@news4.e.nsc.no>,
Tor Rustad <to****@online.no.spam> 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.

"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 <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

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

[Dave Vandervies]

In article <d1*********@news4.newsguy.com>,
Chris Torek <no****@torek.net> 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;
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

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

[Richard Harter]

On 18 Mar 2005 17:29:12 GMT, Chris Torek <no****@torek.net> wrote:

In article <d1**********@yin.interaccess.com>,
Kenny McCormack <ga*****@interaccess.com> wrote:

... I have often wished that C had the "break n" feature of shell.

In article <d1**********@pc-news.cogsci.ed.ac.uk>
Richard Tobin <ri*****@cogsci.ed.ac.uk> 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:
...

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

[Richard Tobin]

In article <d1*********@news4.newsguy.com>,
Chris Torek <no****@torek.net> wrote:

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]

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

[Dave Vandervies]

In article <aY********************@comcast.com>,
Eric Sosman <es*****@acm-dot-org.invalid> 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

[Tor Rustad]

"Chris Torek" <no****@torek.net> wrote in message

Kenny McCormack <ga*****@interaccess.com> wrote:

... I have often wished that C had the "break n" feature
of shell.

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

--
Tor <torust AT online DOT no>

[Kenny McCormack]

In article <aY********************@comcast.com>,
Eric Sosman <es*****@acm-dot-org.invalid> 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.

[Tim Rentsch]

cr*@tiac.net (Richard Harter) writes:

On 18 Mar 2005 17:29:12 GMT, Chris Torek <no****@torek.net> 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, 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.

[Chris Torek]

This is getting off topic, but what the heck... :-)

In article <kf*************@alumnus.caltech.edu>
Tim Rentsch <tx*@alumnus.caltech.edu> 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 due
to 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) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[pete]

Tim Rentsch wrote:

cr*@tiac.net (Richard Harter) writes:

On 18 Mar 2005 17:29:12 GMT, Chris Torek <no****@torek.net> 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, 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.

The last way has two less jumps than the one before it,
whenever a positive number of loops are executed.

--
pete

[Tim Rentsch]

Chris Torek <no****@torek.net> writes:

This is getting off topic, but what the heck... :-)

In article <kf*************@alumnus.caltech.edu>
Tim Rentsch <tx*@alumnus.caltech.edu> 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 due
to 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.

[Kevin Bracey]

In message <d1**********@pc-news.cogsci.ed.ac.uk>
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: [phone]
182-190 Newmarket Road Fax: [phone]
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/

[Giorgos Keramidas]

On 2005-03-18 10:02, David Mathog <ma****@caltech.edu> 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.

[Dave Thompson]

On 18 Mar 2005 17:29:12 GMT, Chris Torek <no****@torek.net> wrote:
<snip>

[% 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