aus zwei for-Schleifen "ausbrechen"

[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.

[DrGreenthumb]

Ich glaub ich kann mich daran erinnern. Soweit ich weiß gings doch aber um Fehlerüberprüfung in C, was man in C++ mit Exceptions hätte lösen können.

Naja, wenn ein erfahrener Programmierer goto verwendet weils das beste ist, ok. Nur dieses allgemeine "goto ist manchmal garnicht so schlecht" als Tip für solche Probleme finde ich nicht richtig.

[Bashar]

DrGreenthumb schrieb:

Ich glaub ich kann mich daran erinnern. Soweit ich weiß gings doch aber um Fehlerüberprüfung in C, was man in C++ mit Exceptions hätte lösen können.

Nö, um den Neustart eines wegen eines empfangenen Signals unterbrochenen Syscalls.

Nur dieses allgemeine "goto ist manchmal garnicht so schlecht" als Tip für solche Probleme finde ich nicht richtig.

Man sagt immer, goto sei zu vermeiden, weil es in 99% der Fälle unangebracht ist. OK. Aber warum läßt man es dann nicht zu, wenn man auf einen der 1% restlichen Fälle trifft?

[HumeSikkins]

Hallo,
also zum Thema "goto ja/nein" kann ich nichts sinnvolles beitragen, da ich bisher noch nie in einer Situation war, in der es mich nach der Verwendung von goto verlangte.
Das mag sicher an der Art der Programme liegen, die ich schreibe und sicher auch an meiner Sozialisation. Wie auch immer.

Der Satz: "Wenn einem kein Name einfällt, hat die Funktion auch keinen Sinn, ausser das goto zu vermeiden"
kommt mir im Zusammenhang dieses Threads aber sehr merkwürdig vor. Wenn mir kein Name einfällt, dann hat imo nicht nur die Funktion keinen Sinn sondern ebenso auch das goto. Dann hat schlicht und einfach die Berechnung/Aktion ein Sinn-Problem (oder ich ein Verständnis-Problem).

Wenn ich in einer (verschachtelten) Schleife an manchen Punkten eine Aktion durchführe, die die Schleife beendet, dann sollte diese Aktion einen ganz bestimmten Sinn haben. In diesem Fall sollte ich diesem Sinn aber auch einen Namen geben können.
Fällt mir kein Name ein, dann scheint mir das ein prinzipielles Problem im Code zu sein. Eines das sich nicht durch goto lösen lässt. Entwder weiß ich, was ich mache und ich kann dem was ich tue einen Namen geben, oder ich weiß es nicht, dann sollte ich mir überlegen, *warum* ich überhaupt das tue was ich tue bzw. ob ich nicht lieber etwas ganz anderes tun sollte.

Ich für meinen Teil habe zumindest die Erfahrung gemacht, dass das Fehlen eines guten Namens ein Hinweis darauf ist, dass ich nicht sicher weiß, was ich eigentlich gerade mache.

Aber wie gesagt: Das ist nur meine Erfahrung und keine allgemeine Aussage zum Thema goto.

[DrGreenthumb]

Bashar schrieb:

Man sagt immer, goto sei zu vermeiden, weil es in 99% der Fälle unangebracht ist. OK. Aber warum läßt man es dann nicht zu, wenn man auf einen der 1% restlichen Fälle trifft?

wenn... ich glaube halt einfach nicht, dass die Fragen die hier so von Anfängern gestellt werden, wirklich am besten mit goto zu lösen sind.