Führt kein Weg an Goto vorbei?
-
Eventuell hilft ein break in einem default: - Zweig der switch-Anweisung?
-
ZenJu schrieb:
@unskilled: das mit "again" hab ich noch nicht ganz verstanden: Soll das meine "while (true)" Schleife ersetzen?
Ja und dann einfach im case TYPE_NOTHING: again = false; break;
-
Oder lager das, was zwischen switch-Anweisung und der folgenden break-Instruktion zu tun ist, in eine Funktion aus, die Du in den Fällen type-file und type-directory noch vor dem dort befindlichen break aufrufst.
Dann brauchst Du ein case type-nothing nicht mehr und der break kann direkt der switch-Anweisung folgen und die while - Schleife abbrechen.
-
Einfach im case TYPE_NOTHING: again = false; break;
dann würden in Zeile 19 die "..." ausgeführt. Da steht nochmal einiges an Code, der übersprungen werden sollte.
Vor diesem dann nochmal eine Prüfung "if (again)" hängen, um ihn im "TYPE_NOTHING" Fall nicht auszuführen, ist es das was du meinst?
@Belli: Das wäre eine Möglichkeit, auch wenn es die Lesbarkeit etwas erschwert. Wenn ich das ganze als Inline-Methode einbaue hätte ich auch keinen allzugroßen Performancenacheil: Achja, wollte ich noch anmerken: Performance ist in der Funktion relativ wichtig, d.h. ich würde gerne (logisch) nicht nötige Flag-Abfragen vermeiden.
-
[quote="ZenJu"]
dann würden in Zeile 19 die "..." ausgeführt. Da steht nochmal einiges an Code, der übersprungen werden sollte.
Wie gesagt, pack die "..." in eine Funktion, die Du in den ersten beiden case-Fällen aufrufst, im letzten nicht (den kannst Du dann auch einsparen).
-
Ach so, dann könntest du Dein Code auch so lasen und vor dem switch
if(fileDescr->objType == TYPE_NOTHING) break;schreiben.
Edit: Belli's Vorschlag ist besser.
-
Edit: Belli's Vorschlag ist besser.Danke, so werd ich's machen. Ist logisch wohl am saubersten und hat auch keine Code-Redundanzen.
Und ich war schon ganz kurz davor, das Goto mit einem Kommentar zu rechtfertigen!
-
ZenJu schrieb:
@Belli: Das wäre eine Möglichkeit, auch wenn es die Lesbarkeit etwas erschwert. Wenn ich das ganze als Inline-Methode einbaue hätte ich auch keinen allzugroßen Performancenacheil: Achja, wollte ich noch anmerken: Performance ist in der Funktion relativ wichtig, d.h. ich würde gerne (logisch) nicht nötige Flag-Abfragen vermeiden.
Sorry, aber das mit der Lesbarkeit ist Blödsinn. Was die Performance angeht, glaube ich nicht, daß ein Funktionsaufruf Dich da in Bedrängnis bringt, probier es einfach aus.
Anderenfalls kommst Du nicht umhin, den letzten case-Fall aus dem switch herauszunehmen und in einer if-Abfrage hinter der switch-Abfrage getrennt abzufragen und im true-Fall dann mit break die Schleife zu verlassen.
Aber das halte ich persönlich für hässlich.
-
Sorry, aber das mit der Lesbarkeit ist Blödsinn
Naja, da ist schon ne Latte an Parametern, die ich übergeben muss. Ich finde schon, dass das die Lesbarkeit erschwert.
Was die Performance angeht...
Das Glaube ich auch nicht. Trotzem möchte ich gerne eine Alternative zu Goto, die von der Performance äquivalent ist. Das wäre für mich der erste Fall, in dem Goto "gewonnen hätte"... ein Armutszeugnis!
-
Also ich hätte bei dem Code kein Problem mit dem goto, sondern eher damit:
while (true) //erlaube "retry", wenn innerhalb des try/catch etwas schiefgehtKommt natürlich auf den hier nicht gezeigten Rest der Funktion drauf an.
-
@hustbaer: Die Funkionalität soll sein: Falls beim Löschen einer Datei ein Fehler auftritt, soll es beliebig oft möglich sein, es nochmal zu versuchen.
Praktisch heißt das, im catch-Block öffnet sich ein Popup, in dem der User angeben kann "Retry" oder "Ignore". Im ersten Fall geht es nochmal durch die endlos while(true)-Schleife, im zweiten Fall wird diese mit einem "break" beendet.
Ich gebe zu, es sieht nicht sehr schön aus, wenn es ein besseres Design gibt, bin ich für Vorschläge immer offen!
-
Ah, ok.
Ich schreibe so selten Code der direkt mit Usern interagieren kann/darf, dass ich an die Möglichkeit garnicht denke.
Das müsste dann schon OK sein. Sah nur irgendwie nach Endlosschleife aus.
