I'm with mhagain's first approach, just make it a function and return from the whole shebang. Exceptions sound terrible as a way out, unless something actually exceptional happened, like ran into a null pointer or some invalid arguments.

On the other hand, i'm not super opposed to a Goto, depending on how it's used, it's pretty common to see windows code like:

{

hr = S_OK // or E_FAIL or whatever

IFC(DoThing1());

IFC(DoThing2());

Clean:

CleanUp();

return hr;

}

with IFC being a macro that checks for failure, assigns hr, and if there was a failure, goto Clean:

In C/C++ the "cleanest" code for breaking from an inner loop:

int i, j;
for(i = 0; i < 10; i++) {
    for(j = 0; j < 10; j++) {
        if(i - 1 == j + 1)
            goto outer;
    }
}
outer:

auto inner = [&](int i) {
   for(int j = 0; j < 10; j++) {
        if(i - 1 == j + 1)
            return false;
   }
   return true;
};
for(int i = 0; i < 10 && inner(i); i++) {}

Another way that occurs to me is to put the nested loop into a try/catch block and throw an exception. I'm not sure if that's elegant or horrible though.

When something looks like goto and walks like goto and smells like goto, too... why not just use goto?

It's not like goto is inherently evil. Yes, there are holy wars going over it all over the internet (and predating the internet) but so what. Someone on the internet is wrong.

It is just what you're doing! You're doing a jump out of a nested loop, don't pretend you're doing anything different. It's exactly what the assembly that the compiler produces will look like, too. And besides, it's pretty close to the "most obvious, least astonishing" way of doing it.

Given the option of simply returning from the surrounding function, I'd choose that, because it avoids using goto for no reason. But in every other case, I wouldn't try to hide the goto that I'm doing secretly.

<lambda>

Awesome approach. But then again, it's setting up a lambda object (with captures and all) for no good reason. The compiler might optimize that out again, but that isn't granted.

Similar is true for any such construct involving function calls of which you can assume but don't know for sure that the compiler will optimize them away.

That's somewhat going against Sutter/Alexandrescu's rule: Don't pessimize prematurely (that one immediately follows "Don't optimize prematurely"). It's not like you're going to use goto all over the place. There are singular cases where goto is just appropriate, and in these singular cases you can just use it. You can, but you probably shouldn't invest both development time and runtime into making something "better" that is already... well... good.

You could also use a boolean.

bool escape = false;
for(int i = 0; i < 10 && !escape; i++)
{
    for(j = 0; j < 10; j++)
    {
        if(i - 1 == j + 1)
        {
            escape = true;
            break;
        }
    }
}