打破嵌套循环的另一种方法是将两个循环分解成一个单独的函数，并在希望退出时从该函数返回。

当然，这也引发了另一个争论，即是否应该显式地从函数的任何地方返回，而不是在函数的末尾。

我不确定这样做是否值得，但你可以用一些简单的宏来模拟Java的命名循环:

#define LOOP_NAME(name) \
    if ([[maybe_unused]] constexpr bool _namedloop_InvalidBreakOrContinue = false) \
    { \
        [[maybe_unused]] CAT(_namedloop_break_,name): break; \
        [[maybe_unused]] CAT(_namedloop_continue_,name): continue; \
    } \
    else

#define BREAK(name) goto CAT(_namedloop_break_,name)
#define CONTINUE(name) goto CAT(_namedloop_continue_,name)

#define CAT(x,y) CAT_(x,y)
#define CAT_(x,y) x##y

使用示例:

#include <iostream>

int main()
{
    // Prints:
    // 0 0
    // 0 1
    // 0 2
    // 1 0
    // 1 1

    for (int i = 0; i < 3; i++) LOOP_NAME(foo)
    {
        for (int j = 0; j < 3; j++)
        {
            std::cout << i << ' ' << j << '\n';
            if (i == 1 && j == 1)
                BREAK(foo);
        }
    }
}

另一个例子:

#include <iostream>

int main()
{
    // Prints: 
    // 0
    // 1
    // 0
    // 1
    // 0
    // 1

    int count = 3;
    do LOOP_NAME(foo)
    {
        for (int j = 0; j < 3; j++)
        {
            std::cout << ' ' << j << '\n';
            if (j == 1)
                CONTINUE(foo);
        }
    }
    while(count-- > 1);
}

Breaking out of a for-loop is a little strange to me, since the semantics of a for-loop typically indicate that it will execute a specified number of times. However, it's not bad in all cases; if you're searching for something in a collection and want to break after you find it, it's useful. Breaking out of nested loops, however, isn't possible in C++; it is in other languages through the use of a labeled break. You can use a label and a goto, but that might give you heartburn at night..? Seems like the best option though.

 bool found = false;
    
    for(int i=0; i < m; ++i){
        for(int j=0; j < n; ++j)
            if(grid[i][j] == '*'){
                q.push(make_pair(i,j));
                found = true;
                break;
            }
        if(found)
            break;
    }

我知道这是一个老帖子，但我觉得这真的需要说，没有其他地方可以说。这里的每个人都使用goto。我只是用了一下。

就像几乎所有的事情一样，goto并不是100%的“非好即坏”。至少有两种用法，我想说，如果你使用goto，而不使用它，你不仅应该是100%的好，而且你的程序会比没有它更可读，因为它让你的意图更加清晰(有一些方法可以避免它，但我发现它们都更笨拙):

打破嵌套循环，和 错误处理(即在函数的末尾跳转到清理例程，以返回失败代码并释放内存。)

Instead of just dogmatically accepting rules like "so-so is 'evil'", understand why that sentiment is claimed, and follow the "why", not the letter of the sentiment. Not knowing this got me in a lot of trouble, too, to the point I'd say calling things dogmatically "evil" can be more harmful than the thing itself. At worst, you just get bad code - and then you know you weren't using it right so long as you heard to be wary, but if you are wracking yourself trying to satisfy the dogmatism, I'd say that's worse.

Why "goto" is called "evil" is because you should never use it to replace ordinary ifs, fors, and whiles. And why that? Try it, try using "goto" instead of ordinary control logic statements, all the time, then try writing the same code again with the control logic, and tell me which one looks nicer and more understandable, and which one looks more like a mess. There you go. (Bonus: try and add a new feature now to the goto-only code.) That's why it's "evil", with suitable scope qualification around the "evil". Using it to short-circuit the shortcomings of C's "break" command is not a problematic usage, so long as you make it clear from the code what your goto is supposed to accomplish (e.g. using a label like "nestedBreak" or something). Breaking out of a nested loop is very natural.

(或者更简单地说:使用goto来跳出循环。我想说那更可取。不要使用goto来创建循环。这是“邪恶的”)。

你怎么知道你是不是太教条了?如果遵循“xyz是邪恶的”规则导致您的代码不太容易理解，因为您试图绕过它(例如在每个循环中添加额外的条件，或一些标志变量，或其他类似的技巧)，那么您很可能是教条主义者。

没有什么比学习良好的思考习惯更能替代良好的编码习惯。前者先于后者，一旦采用前者，后者往往紧随其后。然而，问题是，我经常发现，后者没有得到足够的解释。太多的人只是简单地说“这很糟糕”和“这需要更多的思考”，而没有说思考什么，思考什么，以及为什么。这是一个巨大的耻辱。

(FWIW, in C++, the need to break out of nested loops still exists, but the need for error codes does not: in that case, always use exceptions to handle error codes, never return them unless it's going to be so frequent that the exception throw and catch will be causing a performance problem, e.g. in a tight loop in a high demand server code, perhaps [some may say that 'exceptions' should be 'used rarely' but that's another part of ill-thought-out dogmatism: no, at least in my experience after bucking that dogma I find they make things much clearer - just don't abuse them to do something other than error handling, like using them as control flow; effectively the same as with "goto". If you use them all and only for error handling, that's what they're there for.].)

不，别打断我的表演。这是使用后藤的最后一个据点。