aus zwei for-Schleifen "ausbrechen"

[davie]

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.

[Bashar]

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.

[britney]

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.

[Bashar]

Solche Chefs muss man einfach lieben

[DrGreenthumb]

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.

[britney]

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?

[WoWe]

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.

[MFK]

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.

[DrGreenthumb]

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.

[Cpp_Junky]

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;  
            } 
        }

[Helium]

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.

[Walli]

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.

[DrGreenthumb]

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.

[Helium]

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.

[Walli]

Zum Beispiel wenn man der inneren Schleife keinen Namen zuordnen kann und dementsprechen nicht weiß wie man die Funktion benennen sollt. Dann finde ich es logischer ein goto, oder meinetwegen auch ein Flag zu benutzen anstatt es in eine Funktion auszulagern die "goofy" heißt, nur weil mir nichts besseres eingefallen ist. Aber wie gesagt: Hab in den Jahren die ich mich mit der Programmierung beschäftige ein oder zwei Mal ein goto für Sinnvoller gehalten.

[DrGreenthumb]

aber goto zu verwenden weil einem kein gescheiter name einfällt, kanns auch irgendwie nicht sein.

[Bashar]

Doch klar. Wenn einem kein Name einfällt, hat die Funktion auch keinen Sinn, ausser das goto zu vermeiden. Und an dem Punkt wirds albern.

[davie]

(achtung analogie)
solange du referenzen verwenden kannst, musst du auch keine zeiger verwenden

int &i = *new int(10);

na toll.
Wenn ein Sprachmittel angebracht ist, dann verwende es auch. Wenn es in C++ eben nicht solche break label; wie in Java gibt, nimm eben goto. Wenn es am einfachsten und am verständlichsten ist, spricht doch nichts dagegen

[DrGreenthumb]

Mir gings darum, dass Anfängern hier immer öfter geraten wird evtl. goto zu verwenden. In 99,99999% aller Fälle hätte man das aber mit Funktionen sicherlich schöner lösen können.

Ich war, wie gesagt, noch nie in der Situation, dass ich dachte "Mensch, mit goto wärs einfach, aber das will ich nicht nehmen weil alle sagen das ist doof.".
Seine Funktionen "goofy" zu nennen weil man krampfhaft goto vermeiden will ist auch blöd, aber wann kommt dass denn vor? Goto klingt für mich immer nach Notlösung weil einem nix besseres einfällt.

[Bashar]

DrGreenthumb schrieb:

Ich war, wie gesagt, noch nie in der Situation, dass ich dachte "Mensch, mit goto wärs einfach, aber das will ich nicht nehmen weil alle sagen das ist doof.".

Cool, ich schon. Letztes Jahr beim Buha-Contest, und ich war mir nicht sicher, ob ich Abzug kriege wenn ich goto (sinnvoll) einsetze, also hab ichs kompliziert umgebaut. Das waren zugegeben keine verschachtelten Schleifen. Aber den Thread müsstes hier noch geben, ich bin nur zu faul zum suchen.