Ist goto noch evil...
-
Tim06TR schrieb:
Eisflamme schrieb:
Hier nochmal ganz bewusst der imo schöne Code mit goto:
for(std::size_t n = 0; n < 100; ++n) for(std::size_t m = 0; m < 100; ++m) for(std::size_t l = 0; l < 100; ++l) if(cube[n][m][l] == "Bananenweizen") goto rausHierRufzeichen; else // mach irgendwas rausHierRufzeichen:SCHÖN!
n = 100;
ist das weniger schön ?Es ist ca. 100x weniger schön, und macht ausserdem noch was anderes (die inneren Schleifen werden nicht sofort abgebrochen).
Warum ist es 100x weniger schön? Weil es 100x weniger klar ist. Man muss erstmal 100 Gehirnzellen bemühen um zu verstehen was es tut. Beim
gotoCode reichen 10.Und wenn man es gleich mit
returnstattgotoschreiben würde, dann käme man mit 2-3 Gehirnzellen aus. Also noch besser. Weil klarer.
-
goto ist zurecht verpönt und gewöhnlich überflüssig und vermeidbar!
Man kann es aber trotzdem benutzen, wenn damit der Code übersichtlicher wird (wird er das?). Dann aber bitte nur an das Ende einer Funktion und zum Nachvollziehen sauber kommentiert. Ein break oder return tut es meist auch, um aus einer komplizierten Schleifenkonstruktion auszusteigen.
-
berniebutt schrieb:
Dann aber bitte nur an das Ende einer Funktion und zum Nachvollziehen sauber kommentiert.
Nö. Nicht nur ans Ende.
Und statt zu kommentieren nimmt man besser sprechende Namen.goto label1;//es kann kein Frumpel mehr gestreckt werden ... label1:;//es kann kein Frumpel mehr gestreckt werden ...goto es_kann_kein_Frumpel_mehr_gestreckt_werden; ... es_kann_kein_Frumpel_mehr_gestreckt_werden:; ...
-
goto ist außerdem nützlich, um die bösen if-Blöcke und for-Schleifen aus dem Quellcode zu verbannen: http://www.c-plusplus.net/forum/275649-full
Das geht leider nur mit dem GCC Compiler
if und for, bäh...
-
volkard schrieb:
Nö. Nicht nur ans Ende.
Und statt zu kommentieren nimmt man besser sprechende Namen.Sprechende Namen?
ok!... hell: ... goto nirwana; ... nirwana: ... goto hell; ...Solche Codes aus ersten BASIC-Zeiten habe ich immer sehr geliebt.
fantastico!
-
Schleifen sind sehr wohl durch Intervall und Iterator ersetzbar. Alle in der Praxis auftretenden Schleifen werden höchstens 1e1000-mal durchlaufen, also reichen endliche Intervalle vollkommen aus.
Bleibt noch die Endlosschleife - die tritt in der Praxis nicht auf, weil kein Programm unendlich lange läuft.
-
Und wie willst du eine Schleife ersetzen, bei der du vorher nicht weißt, wie lange sie überhaupt laufen soll? Ich kenne genug Programme, die bestimmte Aktionen so lange wiederholen, bis von außen ein "jetzt ist Schluß" Signal gesendet wird (hab auch selber schon welche geschrieben).
(PS: Und wie ist ein Intervall intern realisiert? Vermutlich auch wieder über eine Schleife, die den Iterator weiterschiebt bis er das Ende erreicht hat)
-
berniebutt schrieb:
... hell: ... goto nirwana; ... nirwana: ... goto hell; ...Na, das ist ja trivial... es gibt z.B. so was:
/* Hier macht jemand viele Sachen und bei Fehler springt er ans Ende der Funktion */ if (err) goto label_a; ... if (err) goto label_b; ... if (err) goto label_c; ... if (err) goto label_d; ... if (err) goto label_e; ... /* keine Fehler, einfach return 0 */ return 0; /* und das ist eine Art "Destruktor" am Ende der Funktion: */ label_e: ... label_d: ... label_b: /* Warum label_b vor label_c... */ ... label_c: ... label_a: ... return err;warum kommt label_b vor label_c...
-
!rr!rr_. schrieb:
Schleifen sind sehr wohl durch Intervall und Iterator ersetzbar. Alle in der Praxis auftretenden Schleifen werden höchstens 1e1000-mal durchlaufen, also reichen endliche Intervalle vollkommen aus.
Bleibt noch die Endlosschleife - die tritt in der Praxis nicht auf, weil kein Programm unendlich lange läuft.
Die Ackermann-Funktion ist nicht LOOP-berechenbar.
Edit: Ein bisschen ausführlicher:
IIRC in den späten Zwanzigern hat man geglaubt, dass man keine Endlosschleife brauchen würde, um Turing-vollständig zu werden. Das trifft jedoch nicht zu. Ackermann hat eine Funktion konstruiert, die durch Turingmaschinen berechenbar ist, aber so schnell wächst, dass sie nicht mit Schleifen berechnet werden kann, bei denen vorher die Anzahl der Durchläufe feststeht.
-
hab' ich gesagt, daß die Anzahl Durchläufe vorher feststehen muß?
Schleifen, die bei Eintreten einer Bedingung abbrechen, lassen sich auch durch Intervall und Iterator ersetzen:
[ 1 to: 1e1000 do: [ :i | 1/(4-i). Transcript show: i ] ] on: Error do: [ Transcript show: 'oops ...' ]. "123oops ..."
-
!rr!rr_. schrieb:
hab' ich gesagt, daß die Anzahl Durchläufe vorher feststehen muß?
Lies doch bitte die Postings von Michael E. und bei Dir unbekannten Begriffen schau sie wenigstens oberflächlich im Netz nach.
-
wozu? hast du mein Posting nicht verstanden?
-
!rr!rr_. schrieb:
wozu? hast du mein Posting nicht verstanden?
Gegenfrage: Hast du überhaupt die grundlegenden Konzepte der Berechenbarkeit verstanden? Du kannst mit endlichen Schleifen nicht alles ausrechnen, egal wie groß die Anzahl der Durchläufe auch gesetzt wird.
-
@!rr!rr_.
Wo ist da jetzt der grundlegende Unterschied zu einer Schleife? Die Semantik ist doch genau die selbe: Ich habe eine Zählervariable i, die von 1 bis 1e1000 läuft und die im Schleifenkörper verwendet werden kann.
Versteh' mich nicht falsch, ich bin auch ein Freund von Sprachen, bei denen man die üblichen Kontrollstrukturen nur mit Hilfe von Funktionen schreiben kann (siehe z.B. Haskell), aber zu sagen "in der OOP braucht man genaugenommen weder goto noch Schleifen, sobald man einen Datentyp "Intervall" hat und einen passenden Iterator." ist doch etwas seltsam, da dein Code von der Semantik her eine ganz normale Schleife ist.Und irgendwo in der Implementierung wird sicherlich auch eine Schleife auftauchen und sei es nur in Form von Rekursion. Oder wie sieht die Implementierung von
1 to: 1e1000 do:aus? Ich kenne Smalltalk nicht, aber ich gehe mal davon aus dasdo:eine Funktion ist, die ja auch irgendwie implementiert sein muss.
-
Trolle vs. Klugscheißer
-
CStoll schrieb:
Gegenfrage: Hast du überhaupt die grundlegenden Konzepte der Berechenbarkeit verstanden?
nö. Hätte ich sollen?
wir reden hier von Sprachelementen von Hochsprachen und nicht von Loop-, While-, Blubb- etc -Berechenbarkeitsklassen.
-
!rr!rr_. schrieb:
CStoll schrieb:
Gegenfrage: Hast du überhaupt die grundlegenden Konzepte der Berechenbarkeit verstanden?
nö. Hätte ich sollen?
wir reden hier von Sprachelementen von Hochsprachen und nicht von Loop-, While-, Blubb- etc -Berechenbarkeitsklassen.
Ja, hättest du
Wenn du zu viel aus einer Sprache rauswirfst, verlässt du den Bereich der Turing-Berechenbarkeit. Und das bedeutet, daß es Probleme gibt, die du mit dieser reduzierten Sprache nicht mehr lösen kannst.goto kannst du in ca. 99,99% aller Fälle durch sauberere Sprachkonstrukte ersetzen, ohne die Berechenbarkeitsklasse der Sprache zu reduzieren, Schleifen und Rekursionen kannst du nicht ohne Einschränkungen weglassen.
-
abc.w schrieb:
berniebutt schrieb:
... hell: ... goto nirwana; ... nirwana: ... goto hell; ...Na, das ist ja trivial... es gibt z.B. so was:
/* Hier macht jemand viele Sachen und bei Fehler springt er ans Ende der Funktion */ if (err) goto label_a; ... if (err) goto label_b; ... if (err) goto label_c; ... if (err) goto label_d; ... if (err) goto label_e; ... /* keine Fehler, einfach return 0 */ return 0; /* und das ist eine Art "Destruktor" am Ende der Funktion: */ label_e: ... label_d: ... label_b: /* Warum label_b vor label_c... */ ... label_c: ... label_a: ... return err;warum kommt label_b vor label_c...
Vermutlich sind die Sprungmarken so angelegt, das sichergestellt ist, das immer das aufgeräumt wird, was auch aufgeräumt werden muss. Die Reihenfolge garantiert dies. Das ist zwar clever, aber nicht sofort ersichtlich.
-
ghjghj schrieb:
Vermutlich sind die Sprungmarken so angelegt, das sichergestellt ist, das immer das aufgeräumt wird, was auch aufgeräumt werden muss. Die Reihenfolge garantiert dies. Das ist zwar clever, aber nicht sofort ersichtlich.
Das ist ein Standard-Trick in C.
-
