Goto considered harmful!? (Fork aus: Welche Sprachfeatures sollte man vermeiden)
-
@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.
-
@DocShoe Was ist Käse? SeppJs Aussage oder Funktionen zu nutzen?
Ich persönlich würde jederzeit die Unterteilung in Funktionen einem goto vorziehen. Da ist deutlich sauberer.
-
Nix Käse. Du möchtest logisch zusammenhängende Dinge zerpflücken, weil du sonst deine Ablaufsteuerung nicht programmiert bekommst? Und dann hast du deine logische Ablaufsteuerung über mehrere Funktionen verteilt, so dass man alle Unterfunktionen kennen muss, um den Code zu verstehen? Das hältst du für eine gute Idee?
-
@SeppJ sagte in Welche Sprachfeatures sollte man vermeiden?:
Nix Käse. Du möchtest logisch zusammenhängende Dinge zerpflücken, weil du sonst deine Ablaufsteuerung nicht programmiert bekommst? Und dann hast du deine logische Ablaufsteuerung über mehrere Funktionen verteilt, so dass man alle Unterfunktionen kennen muss, um den Code zu verstehen? Das hältst du für eine gute Idee?
Wenn mein Code durch die Einrückungen erst mitten auf dem Bildschirm anfängt? Wenn ich in verschiedenen Schleifenrümpfen gotos habe, die an Sprungmarken springen, die ich aufgrund der Anzahl der Zeilen nicht mal sehen kann, weil ich dazu scrollen muss? Ja, dann zerpflücke ich lieber meine Schleifen.
PS:
Der Beweis/use case, dass Schleifen/goto performanter sind als Schleifen/Lambdas/Funktionen steht immer noch aus.
-
@DocShoe sagte in Welche Sprachfeatures sollte man vermeiden?:
PS:
Der Beweis/use case, dass Schleifen/goto performanter sind als Schleifen/Lambdas/Funktionen steht immer noch aus.Mehrere Sprungmarken kannst du überhaupt gar nicht mit Funktionen emulieren. Da kannst du nichts vergleichen. Und es hat doch auch niemand gefragt. Und wenn überhaupt, dann wäre die Schuldigkeit doch bei den Funktionen-als-Ablaufsterung-Vertretern, zu zeigen, dass es keine Nachteile hätte.
-
@DocShoe So wie ich das sehe, geht auch um den umgekehrten Fall. Du hast eine Formel (mit ggf. mehreren Variablen, also 3 Indizes und einem Array (oder auch 2x2=4 Indizes und 2 Arrays - oder sogar 2x4=8 Indizes für 2 4d-Arrays) und ein if - und dann musst du bei Funktionen kompliziert diese Werte alle übergeben, nur um ein goto zu vermeiden? Anstelle von sagen wir 20 Zeilen für die gesamte Funktion hast du nun den relevanten Teil anderswo hin (in eine Funktion) verschoben, sodass man nicht mehr erkennt, was eigentlich genau berechnet wird. Vor allem weil man auch die Funktionsargumente leicht vertauschen kann.
Und wenn die verschachtelten Schleifen jeweils andere Schleifenlevel "break"en sollen, wie machst du das dann?
Achtung: ich sage nicht, dass dieser Usecase häufig vorkommt.
-
@SeppJ sagte in Welche Sprachfeatures sollte man vermeiden?:
@DocShoe sagte in Welche Sprachfeatures sollte man vermeiden?:
PS:
Der Beweis/use case, dass Schleifen/goto performanter sind als Schleifen/Lambdas/Funktionen steht immer noch aus.Mehrere Sprungmarken kannst du überhaupt gar nicht mit Funktionen emulieren. Da kannst du nichts vergleichen. Und es hat doch auch niemand gefragt. Und wenn überhaupt, dann wäre die Schuldigkeit doch bei den Funktionen-als-Ablaufsterung-Vertretern, zu zeigen, dass es keine Nachteile hätte.
Sehe ich anders. C++ best practices und Guidelines raten von goto ab. Dann kommt jemand daher und sagt: "Ich muss das hier benutzen, weil mir sonst Performancenachteile entstehen." Dieser jemand sollte jetzt begründen, warum er goto benutzt und welche Nachteile ihm entstehen, wenn´s er nicht tut. Oder anders gesagt: goto sollte die Ausnahme sein, und dann muss man auch begründen, warum die Ausnahme gerechtfertigt ist.
Edit:
Thread Fork?