break in verschachtelten loops
-
Hallo,
wenn ich ein doppelte schleife habe und in der inneren ein break mache - springt er dann komplett raus aus beiden raus oder macht er dann mit der oberen eins weiter?
-
Er springt natürlich nur aus der inneren Schleife raus. Übrigens: wenn du mal viele verschachtelte Schleifen hast und aus der innersten ganz raus springen willst, ist sogar das verpönte goto ein gangbarer Weg (anstatt in jeder Schleife eine zusätzliche Abbruchbedingung einzufügen).
-
Oder schleifen einfach in ne Fkt zu packen und mit
return;rauszuspringen o.ä.bb
-
wäre das nicht ziemlcih inperformant? In jeder Iteration ein funktionssprung?
-
iuuo schrieb:
wäre das nicht ziemlcih inperformant? In jeder Iteration ein funktionssprung?
nein, da es keine funktionssprünge geben wird.
-
iuuo schrieb:
wäre das nicht ziemlcih inperformant? In jeder Iteration ein funktionssprung?
Alle Schleifen in eine Funktion, weißte?
-
Davon abgesehen sind non-virtual function calls recht billig. Vor allem wenn sie nicht stattfinden
(nicht stattfinden weil sie entweder ge-inlined werden, oder weil die wichtige innerste schleife eben komplett in einer funktion läuft)
-
unskilled schrieb:
Oder schleifen einfach in ne Fkt zu packen und mit
return;rauszuspringen o.ä.bb
Damit hast du allerdings auch nur ein "Highlevel-Goto" gebastelt.
-
Blubbbb schrieb:
unskilled schrieb:
Oder schleifen einfach in ne Fkt zu packen und mit
return;rauszuspringen o.ä.bb
Damit hast du allerdings auch nur ein "Highlevel-Goto" gebastelt.
und genau das is ja der sinn - es hat einfach mal keinen nachteil ggnüber dem goto... im ggnteil - dadurch, dass die fkt kleiner wird, die aufruft wirds höchstens übersichtlicher...
aber gut, dass dus bemerkt hast
bb
-
Blubbbb schrieb:
unskilled schrieb:
Oder schleifen einfach in ne Fkt zu packen und mit
return;rauszuspringen o.ä.bb
Damit hast du allerdings auch nur ein "Highlevel-Goto" gebastelt.
Und?
-
Blubbbb schrieb:
Damit hast du allerdings auch nur ein "Highlevel-Goto" gebastelt.
Ich seh damit auch kein Problem. Du hast eine übersichtliche Funktion und hast nicht zigfach verschachtelte Schleifen z.B. in deiner main und könntest diese z.B. öfters benutzen. Als Goto sehe ich das nicht an.
-
Ich hab vor einer Weile eine Fan-Site gefunden, die sich mit einem 20 Jahre alten Kultspiel beschäftigt und das mit Augenzwinkern der Autoren dekompiliert und für den PC neu aufgebaut hat. Da ich damals ähnliches vorhatte, habe ich mich nochmal voll draufgestürzt und hänge derzeit an dem Punkt, an dem es sinnvoll ist, die ganzen gotos mal rauszuwerfen und echte C-Blöcke einzuführen - automatisiert natürlich. Was ebenso natürlich zu Problemen führt - eins davon ist das Beschriebene. Seinerzeit hat man arg viel Code in eine Prozedur gepackt. Auslagerung könnte eine Lösung sein, ansonsten ist ein goto in der Tat das Lesbarste was mir einfallen würde.
Und wenn wir schon dabei sind:
Hat irgendjemand noch eine Idee, wie man das Ende einer solchen Routine schön hinkriegt - ohne eine Menge von Codeduplikation oder defines?...
Marke1:
Block1
Marke2:
Block2
Marke3:
Block3
}und nein - das sind keine Rest von else-Blöcken.
-
Äh.
Man müsste schon wissen was inetwa da steht, und wann die diversen Sprungmarken angesprungen werden.
-
Der Unterschied zwischen return und goto ist der, dass man mit return explizit angibt, welche Daten durch dieses "Super-break" die Schleife verlassen. Mit dem goto hinterlässt man einfach die Variablen in einem bestimmten Zustand.
Möglicherweise wird das im Endeffekt genau gleich vom Compiler übersetzt und als viel sauberer als goto würde ich die return-Lösung auch nicht bezeichnen. Aber manchmal ist beides besser als seltsam kryptische Abbruchbedingungen in der Schleife
Im Zweifelsfall würde ich die return-Lösung bevorzugen, schon allein deshalb weil diese doppelte Schleife höchst wahrscheinlich eine riesige Schlangenfunktion verursacht. Wenn sich das in Sinneinheiten gliedern lässt ist die Auslagerung der doppelten Schleife in eine extra Funktion gar nicht so abwegig.
geloeschtPS: ifs sind mediumlevel-gotos. Schleifen sind superhighlevel-gotos. Funktionsaufrufe sind hyperhighlevel-gotos.
-
Hast du denn schon ne Idee für den Algorithmus, um die gotos und labels rauszubekommen? Mir würde nämlich nichts einfallen, was dann besseren Code erzeugen würde als bis jz mit den gotos... ^^
Würde mich nämlich mal interessieren
bb
-
funktion hat doch den nachteil dass es ausserhalb der maincode ist. also alle variablen in maincode sind in der funktion nicht mehr gültig
-
xBlackKnightx schrieb:
funktion hat doch den nachteil dass es ausserhalb der maincode ist. also alle variablen in maincode sind in der funktion nicht mehr gültig
Soll ich dir jetzt erklären, wie man ner Fkt Parameter übergibt? Oo
Bevor du jetzt von Rechenzeitverschwendung anfängst: Der Compiler wird es (wenn es sich denn lohnt) eh inlinen - so bald sich das nicht mehr lohnt, wirst du auch keinen Unterschied merken...bb
-
xBlackKnightx schrieb:
funktion hat doch den nachteil dass es ausserhalb der maincode ist. also alle variablen in maincode sind in der funktion nicht mehr gültig
Das hat gerade auch den Vorteil, dass man genau festlegen kann, welche Variablen die Funktion überhaupt zu Gesicht bekommt und welche davon verändert werden dürfen.
-
_matze schrieb:
Er springt natürlich nur aus der inneren Schleife raus. Übrigens: wenn du mal viele verschachtelte Schleifen hast und aus der innersten ganz raus springen willst, ist sogar das verpönte goto ein gangbarer Weg (anstatt in jeder Schleife eine zusätzliche Abbruchbedingung einzufügen).
Endlich eine Daseinsberechtigung für goto!
-
skullyan schrieb:
_matze schrieb:
Er springt natürlich nur aus der inneren Schleife raus. Übrigens: wenn du mal viele verschachtelte Schleifen hast und aus der innersten ganz raus springen willst, ist sogar das verpönte goto ein gangbarer Weg (anstatt in jeder Schleife eine zusätzliche Abbruchbedingung einzufügen).
Endlich eine Daseinsberechtigung für goto!
wenn du auch nur ein wenig gelesen hättest, hättest du gesehen, dass es eben nicht so ist, weils mir return einfach mal viel schöner geht : P
bb
