From the manual:This is unusual, as far as I've seen in C and C++ -- normally the only requirement is that the label is within the same function.

I know use of goto is normally frowned upon, but consider the following small piece of code:
We have some nested loops, in this case to consider the faces of a tetrahedron and stop as soon as we find a face that fits certain conditions. Normally we'd exit a loop with "break", but the only way to do so here would be to have a "break" within each loop, and set another variable to indicate it's time to break, which each loop would check, so it might as well be included as an extra condition in all but the inner-most loop. That's ugly and a little inefficient. Another option would be to put all the loops in a separate function, and use "return" instead of "goto", but this is the only instance where I need these loops since they serve a very specific purpose, and calling a new function for this purpose would be inefficient.

Yes, if I'm so concerned about efficiency I could unroll the loops. But that's not the problem -- it's the balance of efficiency and readability, and the use of "goto" is the most readable in this case. "goto" can lead to spaghetti code, but it can also be used as a deep "break".

So yeah, between the other stuff you guys have going on, if it's not too much trouble, I think it'd be nice if Lite-C was a little more C-like in this regard -- "goto" shouldn't be confined to a label in the same set of winged brackets

I've got nothing against the suggestion to re-implement the old behaviour of goto, but what I do in such a case is the following:

for (i=0; i<4; i++) {
for (j=i+1; j<4; j++) {
for (k=j+1; k<4; k++) {
... do stuff ...
j = 4; i = 4; break;
}
}
}

Oh true! How did I not think of that? That's what I'll do here.

As an example of where goto would be useful, though, consider the case that the i, j, and k variables should be preserved for the rest of the function (which, thankfully, is not the case in my application).

Thanks

Superku, of course your approach is working, but it's not a good style from my point of view as it introduces new dependencies. Whenever you change the limit of the loops you have to remember that you have to adapt the inner assignment as well. That is likely to be forgotten.

I'd introduce a new function, extract the three nested loops to this function and use a return instead of the break.

how about
bFindFace = true;
for (i=0; i<4 && bFindFace; i++) {
for (j=i+1; j<4 && bFindFace; j++) {
for (k=j+1; k<4 && bFindFace; k++) {
bFindFace = false;
... do stuff ...
}
}
}

MrGuest, that works, but it introduces conditions that will be checked for every loop. It's not much, but it's inefficient, and would be avoided if goto behaved a little more like C.

Uhrwerk, I don't want to introduce a function I'm only going to use once, but I agree it's the "cleanest" solution without goto.

I went with Superku's because it's a little more efficient, and I don't need to preserve i or j -- I do everything I need to with them within the loop.

I understand Lite-C isn't the same as C in every respect, but "goto" is really useless here.

Just Copy those vara when you would have used got and the reassign those values back.

Would this work in a while loop?

i really really agree.
I vant old goto - my code have statements vhich cant be vritten in svitch and in break place i have goto to get out of multiple state execution.

"break n" (n - number of loops to break) could be a suitable alternative here, since "goto" is unlikely to be re-implemented, I think.