Kann ich break verwenden, um mehrere verschachtelte 'for'-Schleifen zu beenden?

Question

Ist es möglich, die break Funktion zum Verlassen mehrerer verschachtelter for Schleifen?

Wenn ja, wie würden Sie dabei vorgehen? Können Sie auch kontrollieren, wie viele Schleifen die break Ausgänge?

Answer 1

Wie wäre es damit?

for(unsigned int i=0; i < 50; i++)
{
    for(unsigned int j=0; j < 50; j++)
    {
        for(unsigned int k=0; k < 50; k++)
        {
            //Some statement
            if (condition)
            {
                j=50;
                k=50;
            }
        }
    }
}

Answer 2

Ein Codebeispiel mit goto und ein Etikett, um aus einer verschachtelten Schleife auszubrechen:

for (;;)
  for (;;)
    goto theEnd;
theEnd:

Answer 3

Obwohl diese Antwort bereits gegeben wurde, denke ich, dass ein guter Ansatz darin besteht, folgendes zu tun:

for(unsigned int z = 0; z < z_max; z++)
{
    bool gotoMainLoop = false;
    for(unsigned int y = 0; y < y_max && !gotoMainLoop; y++)
    {
        for(unsigned int x = 0; x < x_max && !gotoMainLoop; x++)
        {
                          //do your stuff
                          if(condition)
                            gotoMainLoop = true;
        }
    }

}

Answer 4

Ich weiß, dass dies ein alter Thread ist, aber ich habe das Gefühl, dass dies wirklich gesagt werden muss, und ich kann es nirgendwo anders sagen. Für alle hier, verwenden Sie goto. Ich habe es gerade benutzt.

Wie fast alles ist auch goto nicht zu 100 % entweder/oder "schlecht" oder "gut". Es gibt mindestens zwei Verwendungszwecke, bei denen ich sagen würde, dass es nicht nur 100%ig in Ordnung ist, wenn man ein goto für diese Verwendungszwecke verwendet - und für nichts anderes -, sondern dass das Programm sogar besser lesbar ist als ohne goto, da es die Intentionen deutlicher macht (es gibt Möglichkeiten, es zu vermeiden, aber ich habe festgestellt, dass sie alle viel umständlicher sind):

1. Ausbrechen aus verschachtelten Schleifen und
2. Fehlerbehandlung (d.h. Sprung zu einer Aufräumroutine am Ende einer Funktion, um einen Fehlercode zurückzugeben und Speicher freizugeben).

Anstatt einfach dogmatisch Regeln wie "so-so ist 'böse'" zu akzeptieren, sollten Sie verstehen pourquoi das Gefühl behauptet wird, und folgen Sie dem "Warum", no den Buchstaben des Gefühls. Das nicht zu wissen, hat mir auch eine Menge Ärger eingebracht, und ich würde sagen, Dinge dogmatisch "böse" zu nennen, kann schädlicher sein als die Sache selbst. Schlimmstenfalls bekommt man einfach nur schlechten Code - und dann weiß man, dass man ihn nicht richtig verwendet hat, solange man gehört hat, dass man vorsichtig sein muss, aber wenn man sich bei dem Versuch, den Dogmatismus zu befriedigen, selbst zerfleischt, würde ich sagen, das ist schlimmer.

Warum "goto" wird "böse" genannt, weil Sie sollten sie niemals als Ersatz für gewöhnliche "ifs", "fors" und "whiles" verwenden. . Und warum das? Probieren Sie es aus, verwenden Sie "goto" anstelle von gewöhnlichen Steuerlogik-Anweisungen, die ganze Zeit, und versuchen Sie dann, denselben Code noch einmal mit der Steuerlogik zu schreiben, und sagen Sie mir, welcher schöner und verständlicher aussieht und welcher eher wie ein Durcheinander. Das war's. (Bonus: Versuchen Sie jetzt, eine neue Funktion zum reinen Goto-Code hinzuzufügen.) Deshalb ist es "böse", mit der passenden Bereichsqualifikation um das "böse". Es zu benutzen, um die Unzulänglichkeiten von C's " break Der Befehl " ist no eine problematische Verwendung, solange Sie aus dem Code deutlich machen, was Ihr goto erreichen soll (z. B. mit einem Label wie "nestedBreak" oder so). Der Ausbruch aus einer verschachtelten Schleife ist sehr natürlich.

(Oder um es einfacher auszudrücken: Verwenden Sie goto, um aus der Schleife auszubrechen. Ich würde sagen, das ist sogar vorzuziehen. Nicht goto verwenden, um erstellen. die Schleife. Das ist "böse").

Und woher weiß man, ob man dogmatisch ist? Wenn das Befolgen einer "xyz ist böse"-Regel dazu führt, dass Ihr Code weniger verständlich, weil Sie sich verrenken, um das Problem zu umgehen (z. B. durch das Hinzufügen zusätzlicher Bedingungen zu jeder Schleife oder einer Flag-Variablen oder eines anderen Tricks), dann sind Sie sehr wahrscheinlich dogmatisch.

Es gibt keinen Ersatz für das Erlernen guter Denken Gewohnheiten, mehr noch als gute Kodierung Gewohnheiten. Die ersteren gehen den letzteren voraus, und die letzteren folgen oft, sobald die ersteren angenommen sind. Das Problem ist jedoch, dass die letzteren viel zu oft nicht angenommen werden. erläutert genug. Zu viele sagen einfach "das ist schlecht" und "darüber muss mehr nachgedacht werden", ohne zu sagen was zu denken, was zu denken über y pourquoi . Und das ist eine große Schande.

(FWIW, in C++ besteht immer noch die Notwendigkeit, aus verschachtelten Schleifen auszubrechen, aber die Notwendigkeit für Fehlercodes nicht: in diesem Fall sollten Sie immer Ausnahmen verwenden, um Fehlercodes zu behandeln, und sie niemals zurückgeben, es sei denn, es wird so häufig vorkommen, dass das Werfen und Abfangen von Ausnahmen ein Leistungsproblem verursacht, z. B. in einer engen Schleife in einem anspruchsvollen Servercode. z. B. in einer engen Schleife in einem anspruchsvollen Servercode, vielleicht [einige mögen sagen, dass "Ausnahmen" "selten verwendet" werden sollten, aber das ist ein weiterer Teil eines schlecht durchdachten Dogmatismus: nein, zumindest nach meiner Erfahrung, nachdem ich mich gegen dieses Dogma gewehrt habe, finde ich, dass sie die Dinge viel klarer machen - missbrauchen Sie sie einfach nicht, um etwas zu tun andere als Fehlerbehandlung, z. B. Verwendung als Kontrollfluss; im Grunde dasselbe wie bei "goto". Wenn Sie sie alle und nur zur Fehlerbehandlung verwenden, sind sie genau dafür da.].

Answer 5

Eine gute Möglichkeit, aus mehreren verschachtelten Schleifen auszubrechen, besteht darin, Ihren Code in eine Funktion umzuwandeln:

void foo()
{
    for(unsigned int i=0; i < 50; i++)
    {
        for(unsigned int j=0; j < 50; j++)
        {
            for(unsigned int k=0; k < 50; k++)
            {
                // If condition is true
                return;
            }
        }
    }
}