break to witch scope??

[Chris Torek]

This is getting off topic, but what the heck...

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.

 

[pete]

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.

 

[Tim Rentsch]

This is getting off topic, but what the heck...

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]

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.

 

[Giorgos Keramidas]

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]

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