aus zwei for-Schleifen "ausbrechen"
-
goto ist imo am klarsten
funktionen sind auch ok, kann aber verwirrend werden
-
Mit dem goto wäre ich vorsichtig, ist schlechtes C/C++.
-
das ist aber eine der wenigen sachen, an denen goto angemessen sein kann.
undfor (int f=1; f<n+1; f++) for (int g=1; g<m+2; g++) { if (A[f][g+1] == 1) goto ende; } ende:
ist nicht unbedingt unleserlich und vor allem nicht sofort schlechtes cpp.
-
Naja, in letzter Zeit liest man hier öfter das goto angemessen sein kann. Mag ja stimmen. Aber gebraucht hab ichs noch nie, auch ohne solche Konstrukte wie hier von Cpp_Junky.
Und wenn jemand gerade noch mit der C++-Syntax kämpft finde ich's besser zu sagen das goto schlecht ist und nicht verwendet werden sollte.
-
ist ok so. es kommt eben auf den stil an:
brauche ich geschachtelte schleifen, dann muss ich in kauf nehmen, uU goto zu verwenden; im allgemeinen ist der code dann länger - nicht unbedingt komplizierter
allerdings lässt sich auch so designen, dass niemals eine geschachtelte schleife verwendet werden muss, oder zumindest so, dass goto unnotwendig ist.
brauche ich mehrdimensionale arrays? etc.
-
davie schrieb:
allerdings lässt sich auch so designen, dass niemals eine geschachtelte schleife verwendet werden muss, oder zumindest so, dass goto unnotwendig ist.
eben.. also lieber darüber nachdenken als sich mit nem goto aus der Affäre ziehen.
-
ist ok so. es kommt eben auf den stil an:
brauche ich geschachtelte schleifen, dann muss ich in kauf nehmen, uU goto zu verwenden; im allgemeinen ist der code dann länger - nicht unbedingt komplizierter
allerdings lässt sich auch so designen, dass niemals eine geschachtelte schleife verwendet werden muss, oder zumindest so, dass goto unnotwendig ist.
brauche ich mehrdimensionale arrays? etc.
-
DrGreenthumb schrieb:
eben.. also lieber darüber nachdenken als sich mit nem goto aus der Affäre ziehen.
Das Nachdenken wird aber manchmal auch ergeben, dass goto die eleganteste Lösung ist. Das von vornherein zu verteufeln halte ich nicht für gut. goto ist nicht per se schlecht, es ist dann schlecht, wenn damit unübersichtliche Programme gebaut werden.
-
Und schon wieder die schöne goto-Diskussion ;)! Ich persönlich finde goto ja in einem übersichtlichen Rahmen auch okay, aber da mein "Chef" davon gar nichts hält, werde ich hier was anderes machen müssen:
"f = n + 1;" als break-Statement für die äußere Schleife finde ich ganz lustig.
-
Solche Chefs muss man einfach lieben
-
Bashar schrieb:
Das Nachdenken wird aber manchmal auch ergeben, dass goto die eleganteste Lösung ist. Das von vornherein zu verteufeln halte ich nicht für gut. goto ist nicht per se schlecht, es ist dann schlecht, wenn damit unübersichtliche Programme gebaut werden.
Da bin ich mir nicht so sicher. Wenn man schon 2 verschachtelte Schleifen mit einer if-Abfrage drin hat ist die Funktion ja schon so groß, dass es sich anbietet 'ne extra Funktion zu schreiben, anstatt hinter der Schleife noch weiter zu machen.
Naja, gibt immer Ausnahmen, aber kam mir noch nie vor. Also verteufel ich lieber als dazu zu raten.
-
DrGreenthumb schrieb:
Da bin ich mir nicht so sicher. Wenn man schon 2 verschachtelte Schleifen mit einer if-Abfrage drin hat ist die Funktion ja schon so groß, dass es sich anbietet 'ne extra Funktion zu schreiben, anstatt hinter der Schleife noch weiter zu machen.
Da könnte man mal die Frage stellen: Wie groß darf denn eine Funktion maximal sein? Es wird ja auch schnell unübersichtlich, wenn man tausend Mini-Funktionen hat. Dann doch lieber mal eine mit mehr als 20 Zeilen Code, oder?
-
Kommt ganz drauf an wie oft die Schleife aufgerufen wird. Wird sie oft aufgerufen sind Flags besser, wird sie nur ab und zu aufgerufen, ist eine eigene Funktion mit return besser. Kurz und knackig.
-
britney schrieb:
"f = n + 1;" als break-Statement für die äußere Schleife finde ich ganz lustig.
Das halte ich übrigens für eine der schlechtesten Lösungen (zusammen mit Exceptions), weil man dann zwei Stellen im Code ändern muss, wenn sich die Schleifenbedingung ändert. Und die beiden Stellen müssen nicht so nahe beieinander liegen.
So etwas ist sehr wartungsunfreundlich.
-
britney schrieb:
Da könnte man mal die Frage stellen: Wie groß darf denn eine Funktion maximal sein? Es wird ja auch schnell unübersichtlich, wenn man tausend Mini-Funktionen hat. Dann doch lieber mal eine mit mehr als 20 Zeilen Code, oder?
Mehr als 20?
Du musst bedenken dass tausend Mini-Funktionen den Code durch ihre Namen gleich mitkommentieren.Aber ich würde mich da nicht auf Zahlen festlegen. Kommt ja auf den Code an. Wenn's einfach aneinandergereihte Anweisungen sind, ist es ja nicht unübersichtlich.
Schlimm wirds dann spätestens bei mehrfach verschachtelten Schleifen wo auch noch laufend irgendwelche Variablen verändert werden.WoWe schrieb:
Kommt ganz drauf an wie oft die Schleife aufgerufen wird. Wird sie oft aufgerufen sind Flags besser, wird sie nur ab und zu aufgerufen, ist eine eigene Funktion mit return besser.
Wenn's nun nicht gerade _extrem_ auf Geschwindigkeit ankommt, würde ich aber nie zu Lasten der Übersicht auf Funktionen verzichten.
-
Was heisst hier hässlicher Hack ?
Ok, geht auch schöner:bool bWeiter = true; for (int f=1; f<n+1 && bWeiter; f++) for (int g=1; g<m+2; g++) { if (A[f][g+1] == 1) { bWeiter = false; break; } }
-
Da könnte man mal die Frage stellen: Wie groß darf denn eine Funktion maximal sein? Es wird ja auch schnell unübersichtlich, wenn man tausend Mini-Funktionen hat. Dann doch lieber mal eine mit mehr als 20 Zeilen Code, oder?
Grundlegend gilt heute: Eine Funktion übernimmt eine Aufgabe. Dabei gibt es immer mindestens eine Funktion, die nur die Aufgabe hat andere Funktionen aufzurufen.
Google mal nach Refaktorisierung oder vermutlich besser englisch Refactoring.
-
Jemand der es von vorne herein ablehnt darf ruhig als ahnungslos bezeichnet werden. Natürlich kann man so umschreiben, dass ein goto in jedem Fall redundant wird, aber, wie Bashar schon sagte, kommt man manchmal zu dem Schluß dass goto am elegantesten ist. In den meisten Fällen würde ich vorschlagen eine Schleife in eine Funktion auszulagern. Wenn das allerdings unlogisch wäre dann goto.
-
MaSTaH schrieb:
Jemand der es von vorne herein ablehnt darf ruhig als ahnungslos bezeichnet werden. Natürlich kann man so umschreiben, dass ein goto in jedem Fall redundant wird, aber, wie Bashar schon sagte, kommt man manchmal zu dem Schluß dass goto am elegantesten ist. In den meisten Fällen würde ich vorschlagen eine Schleife in eine Funktion auszulagern. Wenn das allerdings unlogisch wäre dann goto.
Alles nur Theorien. Ich wette niemand findet ein Beispiel wo es wirklich zutrifft.
-
Könnte was drann sein, da ich in den letzten 5 Jahen das Wort GOTO nur in Foren geschreiben habe. Aber ich bn nur ein Programmierer von vielen.