Goto considered harmful!? (Fork aus: Welche Sprachfeatures sollte man vermeiden)
-
@Quiche-Lorraine sagte in Welche Sprachfeatures sollte man vermeiden?:
@Mond
Du hast goto vergessen. Ein Mittel was man heutzutage überhaupt nicht mehr benötigt, aber manchmal noch sieht und Spagetti-Code vom Feinsten produziert!Es ist in C++ bei SciTech-Code noch immer notwendig, wenn man verschachtelte Schleifen schreiben muss. Ein
return
ist da auch keine Alternative.
-
@john-0 sagte in Welche Sprachfeatures sollte man vermeiden?:
@Quiche-Lorraine sagte in Welche Sprachfeatures sollte man vermeiden?:
@Mond
Du hast goto vergessen. Ein Mittel was man heutzutage überhaupt nicht mehr benötigt, aber manchmal noch sieht und Spagetti-Code vom Feinsten produziert!Es ist in C++ bei SciTech-Code noch immer notwendig, wenn man verschachtelte Schleifen schreiben muss. Ein
return
ist da auch keine Alternative.Dann zeig bitte mal ein Beispiel, in dem man zwingend ein
goto
braucht.
-
-
@john-0 Was ist denn SciTech Code? Mir ist in technischen Forschungseinrichtungen bisher kein goto über den Weg gelaufen. Bin zwar jetzt schon ein paar Jahre da raus, aber zumindest damals hätten die Kollegen mir ein goto auch ordentlich um die Ohren gehauen.
Meiner Meinung nach, kann man in C++ immer auf goto verzichten und mir ist noch nie ein Problem untergekommen, dass man mit einem goto eleganter lösen kann.
-
@DocShoe sagte in Welche Sprachfeatures sollte man vermeiden?:
Dann zeig bitte mal ein Beispiel, in dem man zwingend ein
goto
braucht.Es wurde doch bereits erwähnt: mehrfach verschachtelte Schleifen enthalten zuweilen Abbruchbedingungen bei denen man aus einer inneren Schleife herausspringen muss. Das
break
funktioniert bei C++ nur über eine Ebene. Die Frage ist auch nicht, ob man das anders schreiben kann, sondern ob das sinnvoll ist. Fortran enthält für solche Fälle die Funktionalität Schleifen zu benennen und sie dann gezielt verlassen zu können bzw. vorzeitig die Verarbeitung in einem Durchlauf abzubrechen und den nächsten Wert zu nehmen.@Swordfish sagte in Welche Sprachfeatures sollte man vermeiden?:
Was ist das?
Das ist eine Kurzform von scientific und technical, und genau in diesem Bereichen hat man halt immer wieder einmal solche Schleifen.
-
Das klassische Beispiel für goto, wenn man mit Gewalt einen Anwendungsfall konstruieren möchte, sind Algorithmen, die irgendwelche verschachtelten Dinge durchgehen, wo dann in einer tiefen Schachtelebene feststellt, dass man ein ein continue für eine der der obersten Ebenen haben kann. Etwa:
for(1) { for(2) { for(3) { for(4) { if (abbruchbedingung) goto continue1; } } } :continue1 }
An den Haaren herbeigezogen? Eigentlich gar nicht mal, das ist durchaus ein realistischer Algorithmus. Aber kommt einem auch nicht jeden Tag unter, sondern das ist meist etwas, das man ein einziges Mal in der allerinnersten Funktion hat.
PS: *john 0 war schneller.
-
@john-0 sagte in Welche Sprachfeatures sollte man vermeiden?:
@DocShoe sagte in Welche Sprachfeatures sollte man vermeiden?:
Dann zeig bitte mal ein Beispiel, in dem man zwingend ein
goto
braucht.Es wurde doch bereits erwähnt: mehrfach verschachtelte Schleifen enthalten zuweilen Abbruchbedingungen bei denen man aus einer inneren Schleife herausspringen muss. Das
break
funktioniert bei C++ nur über eine Ebene. Die Frage ist auch nicht, ob man das anders schreiben kann, sondern ob das sinnvoll ist. Fortran enthält für solche Fälle die Funktionalität Schleifen zu benennen und sie dann gezielt verlassen zu können bzw. vorzeitig die Verarbeitung in einem Durchlauf abzubrechen und den nächsten Wert zu nehmen.@Swordfish sagte in Welche Sprachfeatures sollte man vermeiden?:
Was ist das?
Das ist eine Kurzform von scientific und technical, und genau in diesem Bereichen hat man halt immer wieder einmal solche Schleifen.
Eine Schleifenhierachie als Lambda implementieren und per return rausspringen kommt ganz ohne goto aus. Hängt vllt vom Kontext ab, aber hört sich erstmal machbar an. Vllt nicht bei High Performance Computing, wo du die Captures dann erst mal auf den Stack gelegt werden müssen und bei großen äußeren Schleifen für Performanceeinbruch sorgen.
Gibt´s in C++ nicht so ne Faustregel, dass alles, was man einen Namen geben kann, eine Funktion oder Objekt sein sollte?
-
@DocShoe sagte in Welche Sprachfeatures sollte man vermeiden?:
Vllt nicht bei High Performance Computing
Genau über diesen Bereich reden wir hier aber.
-
@john-0 sagte in Welche Sprachfeatures sollte man vermeiden?:
Das ist eine Kurzform von scientific und technical, und genau in diesem Bereichen hat man halt immer wieder einmal solche Schleifen.
Ja, das habe ich mir schon gedacht. Aber warum kann mann da solche Schleifen nicht in Funktionen packen und mit
return
rausspringen. Erschließt sich mir nicht. Non-Argument.
-
@john-0 sagte in Welche Sprachfeatures sollte man vermeiden?:
@DocShoe sagte in Welche Sprachfeatures sollte man vermeiden?:
Vllt nicht bei High Performance Computing
Genau über diesen Bereich reden wir hier aber.
In diesem Bereich bist du. Hier ist die Rede von Features, die man in modernem (oder gar postmodernem) C/C++ vermeiden sollte. Mikrooptimierungen waren hier nie ein Thema, mit dem Argument kann man haufenweise Zeugs rechtfertigen. Und den Beweis, dass das wirklich performanter ist steht auch noch aus.
-
@DocShoe sagte in Welche Sprachfeatures sollte man vermeiden?:
In diesem Bereich bist du.
Das ist der Bereich in dem man
goto
nutzt, und es ist eine legitime Nutzung vongoto
. Mit der Begründung das wird ja nur von wenigen genutzt könnte man in C++ etliches herauswerfen.
-
@john-0 Du hast noch immer keine Beispiele gebracht. Auf meinen Einwand bist Du auch nicht eingegangen.
-
@Swordfish sagte in Welche Sprachfeatures sollte man vermeiden?:
@john-0 Du hast noch immer keine Beispiele gebracht. Auf meinen Einwand bist Du auch nicht eingegangen.
Was ist, wenn du mal zwei, mal drei Ebenen rausspringen willst?
-
@SeppJ Condition variable?
-
@SeppJ
Ich denke @Swordfish meint dass man immer alles einfach aufreturn
umstellen kann. Was halt nicht so ist. Das geht schon oft recht schön, aber manchmal ginge es nur mit Verrenkungen die man nicht machen will weil a) viel Arbeit und b) sie den Code übelst verschlimmern würden.Und ich hoffe dass er nicht meint man solle zusätzliche Kontrollvariablen verwenden nur um das
goto
zu vermeiden. Würde mich auch wundern wenn er das meint. Obwohl ich Leute gesehen habe die schöne, saubere Loops mitbreak
so umgeschrieben haben.
Ich fände es gut wenn C++ zu diesem Zweck die
break
Syntax aufbohren würde, so dass man z.B.break my_label;
schreiben kann. Was dann das selbe machen sollte wiegoto my_label;
, nur mit der Einschränkung dass es einen Fehler gibt wenn die Position des Labels nicht einem reinen "multi level break" entspricht.
-
@hustbaer sagte in Welche Sprachfeatures sollte man vermeiden?:
Ich denke @Swordfish meint dass man immer alles einfach auf return umstellen kann.
Immer alles? Nein. Oft bis fast immer? Ja.
Wenn es nur mit Verrenkungen geht dann bin ich natürlich auch für eine Sprungmarke. Aber wenn es anders geht, dann bitte anders. Deswegen wollte ich ja auch von @john-0 ein nachvollziehbares Beispiel haben.
-
@Swordfish sagte in Welche Sprachfeatures sollte man vermeiden?:
@SeppJ Condition variable?
Future?
Semaphor?
Mutex?Und: nein, bitte nicht! Unnötige "exit_my_middle_loop" Variablen sind zum Kotzen. Das macht doch alles nur unglaublich unübersichtlich und mühsam zu lesen. Und fehleranfällig.
-
Variable.
@hustbaer sagte in Welche Sprachfeatures sollte man vermeiden?:
Und: nein, bitte nicht! Unnötige "exit_my_middle_loop" Variablen sind zum Kotzen. Das macht doch alles nur unglaublich unübersichtlich und mühsam zu lesen. Und fehleranfällig.
Ja. Ich warte noch immer auf das real world example.
-
@Swordfish sagte in Welche Sprachfeatures sollte man vermeiden?:
Variable.
@hustbaer sagte in Welche Sprachfeatures sollte man vermeiden?:
Und: nein, bitte nicht! Unnötige "exit_my_middle_loop" Variablen sind zum Kotzen. Das macht doch alles nur unglaublich unübersichtlich und mühsam zu lesen. Und fehleranfällig.
Ja. Ich warte noch immer auf das real world example.
Das war ein real world example. Du wirst dir doch wohl vorstellen können, dass es viele Algorithmen gibt, bei denen man bei Erreichen einer bestimmten Bedingung einen zugehörigen Pfad abbrechen will und mit dem nächsten weiter macht. Wer das mit unnötigen Condition-Variablen im inneren Loop macht, gehört nicht an Computerzeit gelassen. Wer seine verschachtelten Loop nur zwecks Ablaufsteuerung in Unterfunktionen verteilt, gehört ebenfalls nicht an ein Computerprogramm.
-
@SeppJ sagte in Welche Sprachfeatures sollte man vermeiden?:
...
Wer seine verschachtelten Loop nur zwecks Ablaufsteuerung in Unterfunktionen verteilt, gehört ebenfalls nicht an ein Computerprogramm.Das ist einfach nur Käse...
Die Aussage ist einfach nur Käse...Edit für Tyrdal:
Sepp´s Aussage.