was die goto s angeht:

HumeSikkins

Tim schrieb:

Bashar schrieb:

http://www.kbs.uni-hannover.de/Lehre/SWTG/goto.pdf

Mehr gibt es dazu nicht zu sagen.

Sicher?

http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf

Der zweite Artikel ist ein Paradebeispiel für das, was mich an der Diskussion immer am meisten stört: die Komplexität des gezeigten Codes kommt imo nicht von der Verwendung oder Nicht-Verwendung von goto sondern schlicht daher, das der Code nur indirekt ausdrückt was er tut. Die Aufgabe ist:

Write a program
that will print the number of the
first all-zero row of X, if any.”

Der Code enthält aber nirgends den Ausdruck "all-zero row", da die Sprache kein solches Konstrukt anbietet. Stattdessen muss ein Workaround benutzt werden - im Sinne von Brooks würde man das wohl als "accidental complexity" bezeichnen.
Die meisten Fälle von goto, die ich kenne, beziehen sich auf solche Situationen - Workarounds für Dinge, die sich in der Sprache nicht natürlich ausdrücken lassen. Workarounds sollten aber imo a) selten und b) lokal-begrenzt sein, deshalb verstehe ich nicht, warum man da so heftig drüber streitet.
Interessanter fände ich die Frage, ob es Fälle gibt, wo goto wirklich elegant ist. Ansonsten bleibt für mich goto einfach häufig nur das geringste aller Übel und damit kaum der Rede wert.

Btw: Der naheliegenste Workaround für das konkrete Beispiel wäre imo die Verwendung einer Funktion:

for (int i = 0; i < N; ++i) {
  if (allZero(x[i], N)) {
    printf("First all-zero %d\n", i);
    break;
  }
}
// oder in C++ (zugegebenermaßen häßlich)
for (int i = 0; i < N; ++i) {
  if (find_if(x[i], x[i]+N, not1(bind2nd(equal_to<int>(), 0))) == x[i]+N) {
    printf("First all-zero %d\n", i);
    break;
  }
}

Jetzt kann man natürlich sagen, dass der Aufruf einer Funktion doch viel zu teuer ist. Das wäre dann aber kein Argument für/wider goto sondern nur ein Zeichen dafür, dass das Sprachmittel "Funktion" kaputt ist. Und wenn ich dann wirklich die Situation habe, wo ich partout keine Funktion verwenden kann, dann scheint es in meinen Augen ziemlich wurscht zu sein, ob man nun ein goto verwendet oder ein flag. Ich würde wohl das goto nehmen, aber ich traue mir auch zu, den nicht-goto-Code zu verstehen.

Mr. N

HumeSikkins schrieb:

Jetzt kann man natürlich sagen, dass der Aufruf einer Funktion doch viel zu teuer ist.

allZero würde ich als Template implementieren, wäre also immer inline-bar. Warum wird der Optimierer ständig so unterschätzt?

Undertaker

HumeSikkins schrieb:

Die meisten Fälle von goto, die ich kenne, beziehen sich auf solche Situationen - Workarounds für Dinge, die sich in der Sprache nicht natürlich ausdrücken lassen. Workarounds sollten aber imo a) selten und b) lokal-begrenzt sein, deshalb verstehe ich nicht, warum man da so heftig drüber streitet.
Interessanter fände ich die Frage, ob es Fälle gibt, wo goto wirklich elegant ist.

naja, wenn man jeden kleinkram in funktionen zerlegt, kriegt man jedes 'goto' weg.
aber ich würde es eher so sehen, dass das 'zerlegen in funktionen' der workaround ist und nicht die verwendung von 'goto'.
sinnvoll finde ich das 'aufräum und tschüss'-goto. das bekommt man natürlich auch dadurch weg, dass man für den inneren code eine extra funktion schreibt, aus der man im fehlerfall mit return herausspringt (aber dann beschweren sich wieder leute, die meinen eine funktion dürfe nur einen austrittspunkt haben), während die aufrufende funktion sich um speicherfreigabe etc. kümmert.
aber extra eine funktion zu schreiben, die ausschliesslich aus dem grund existiert, weil man ein 'goto' vermeiden will, finde ich falsch.

Mr. N

Undertaker schrieb:

naja, wenn man jeden kleinkram in funktionen zerlegt, kriegt man jedes 'goto' weg.
aber ich würde es eher so sehen, dass das 'zerlegen in funktionen' der workaround ist und nicht die verwendung von 'goto'.

Klingt erstmal absurd. Begründe das doch bitte.

Undertaker schrieb:

sinnvoll finde ich das 'aufräum und tschüss'-goto.

Allgemein wird die Notwendigkeit für ein Aufräum-und-Tschüss-Goto in C++ durch Destruktoren, try{}catch{}-Blöcke und Exceptions weit geringer als in C. (Geringer aber ungleich Null.)

HumeSikkins

Mr. N schrieb:

HumeSikkins schrieb:

Jetzt kann man natürlich sagen, dass der Aufruf einer Funktion doch viel zu teuer ist.

allZero würde ich als Template implementieren, wäre also immer inline-bar. Warum wird der Optimierer ständig so unterschätzt?

Habe gehört, dass es Sprachen gibt, die keine Templates bieten (z.B. C).

@Undertaker
Hast du die Aussage meines Postings überhaupt verstanden? Mir geht es gar nicht um "goto weg kriegen" oder um das "zerlegen in funktionen" sondern um die Lücke zwischen dem was man sagen will und dem was man sagen kann. In der Problembeschreibung findest du nirgends ein goto, ein Flag oder eine Schleife. Trotzdem muss die Lösung solche Konstrukte beinhalten. Und das nicht, weil goto/Flags/Schleifen so elegant sind, sondern weil die Lösung in der Sprache nicht anders ausgedrückt werden kann.
Meiner Meinung nach sollte man die Lücke zwischen Beschreibung und Code so klein wie möglich halten und dazu *jedes* Sprachmittel einsetzen, was dabei hilft (z.B. lieber ein Algo wie std::find, statt einer expliziten for-Schleife, denn niemand sagt "loop through all the elements x and check if x is equal to y", wenn er auch "if bla contains y" sagen kann). Die Stellen, wo die Lücke bleibt, sollten lokal-begrenzt sein, da sie dann nicht so sehr ins Gewicht fallen: eine komplexe Funktion voller Workarounds ist besser als 20 Workaround über den gesamten Code verstreut.
Genau aus dieser Perspektive verstehe ich die Diskussionen um goto nicht: es macht dann nämlich schlicht keinen großen Unterschied, ob man nun goto verwendet oder nicht. Anders sieht es aus, wenn ich wie ein Irrer durch mein Programm hüpfe und dabei jede Form der logischen Aufteilung vergesse.

Oder anders: Um was geht es bei der goto-Diskussion denn eigentlich? Wenn es wirklich nur um das Sprachkonstrukt geht, finde ich die Diskussion albern. Geht es hingegen um die sinnvolle Strukturierung von Code, dann ist das Ganze interessant, hat aber nichts mit goto per se zu tun.

Undertaker

Mr. N schrieb:

Undertaker schrieb:

naja, wenn man jeden kleinkram in funktionen zerlegt, kriegt man jedes 'goto' weg.
aber ich würde es eher so sehen, dass das 'zerlegen in funktionen' der workaround ist und nicht die verwendung von 'goto'.

Klingt erstmal absurd. Begründe das doch bitte.

naja, man macht sich doch funktionen die z.b. teilaufgaben erledigen, um sein programm zu modularisieren usw. so'ne funktion bekommt einen namen, der möglichst deutlich macht, was die funktion tut, eventuell noch ein kommentar darüber etc.
das ganze dient dazu, ein programm lesbar und übersichtlich zu halten. wenn man jetzt anfängt, funktionen zu schreiben, die nur deshalb da sind, weil man auf teufel-komm-raus keine 'gotos' haben will, dann versemmelt man sich damit das ganze 'design'. mich z.b. würde es sehr stören, wenn ich eine funktion nur deshalb schreiben müsste, um ein 'goto' zu vermeiden. wie soll ich diese funktion nennen? 'AvoidFuckingGoto3()'? was schreibe ich als kommentarzeile darüber? 'diese funktion darf nur von XXX aufgerufen werde und es gibt sie nur, weil sonst ein 'goto' in XXX wäre?

HumeSikkins schrieb:

Meiner Meinung nach sollte man die Lücke zwischen Beschreibung und Code so klein wie möglich halten und dazu *jedes* Sprachmittel einsetzen, was dabei hilft
...
Die Stellen, wo die Lücke bleibt, sollten lokal-begrenzt sein, da sie dann nicht so sehr ins Gewicht fallen: eine komplexe Funktion voller Workarounds ist besser als 20 Workaround über den gesamten Code verstreut.

das sehe ich auch so.

HumeSikkins schrieb:

Genau aus dieser Perspektive verstehe ich die Diskussionen um goto nicht: es macht dann nämlich schlicht keinen großen Unterschied, ob man nun goto verwendet oder nicht.

richtig, aber leider denken viele: 'um himmels willen, bloss kein goto in meinem programm!'. und vielleicht ist dieser djikstra daran schuld mit seinem artikel von anno dunnemals

HumeSikkins schrieb:

Oder anders: Um was geht es bei der goto-Diskussion denn eigentlich? Wenn es wirklich nur um das Sprachkonstrukt geht, finde ich die Diskussion albern. Geht es hingegen um die sinnvolle Strukturierung von Code, dann ist das Ganze interessant, hat aber nichts mit goto per se zu tun.

es wird wohl um beides gehen. jedenfalls, in programmiersprachen, bei denen man den kontrollfluss bestimmen kann (mit schleifen, if-then-else, funktionen usw.) gehört ein 'unbedingter sprung' einfach dazu. auch wenn man ihn sehr selten benötigt, aber wenn man ihn braucht, ist es gut, wenn es ihn gibt.

hustbaer

Undertaker schrieb:

HumeSikkins schrieb:

Genau aus dieser Perspektive verstehe ich die Diskussionen um goto nicht: es macht dann nämlich schlicht keinen großen Unterschied, ob man nun goto verwendet oder nicht.

richtig, aber leider denken viele: 'um himmels willen, bloss kein goto in meinem programm!'. und vielleicht ist dieser djikstra daran schuld mit seinem artikel von anno dunnemals

Nein, es sind Leute schuld die mit "gogo" z.B. solchen Code schreiben (s.u.), und Leute die nicht kapieren dass der nicht wegen dem "goto" schlecht ist, sondern einfach weil der "Programmierer" der sowas schreibt eins an der Waffel hat.

void foo()
{
	//...
	while (blah())
	{
		int z = 1;
		xyz1();
	fump:
		xyz2(z);
		xyz3();
	}

	bar();
	if (!baz())
		goto fump;
}

Mr. N

HumeSikkins schrieb:

Mr. N schrieb:

HumeSikkins schrieb:

Jetzt kann man natürlich sagen, dass der Aufruf einer Funktion doch viel zu teuer ist.

allZero würde ich als Template implementieren, wäre also immer inline-bar. Warum wird der Optimierer ständig so unterschätzt?

Habe gehört, dass es Sprachen gibt, die keine Templates bieten (z.B. C).

Habe gehört, dass es Sprachen gibt, in denen es keine Funktionen gibt... Ich dachte immer, dass wir hier, wenn nichts explizit angegeben ist, von C++ ausgehen. Zumal deine Code-Beispiele reinstes C++ waren.

Undertaker schrieb:

naja, man macht sich doch funktionen die z.b. teilaufgaben erledigen, um sein programm zu modularisieren usw. so'ne funktion bekommt einen namen, der möglichst deutlich macht, was die funktion tut, eventuell noch ein kommentar darüber etc.
das ganze dient dazu, ein programm lesbar und übersichtlich zu halten. wenn man jetzt anfängt, funktionen zu schreiben, die nur deshalb da sind, weil man auf teufel-komm-raus keine 'gotos' haben will, dann versemmelt man sich damit das ganze 'design'. mich z.b. würde es sehr stören, wenn ich eine funktion nur deshalb schreiben müsste, um ein 'goto' zu vermeiden. wie soll ich diese funktion nennen? 'AvoidFuckingGoto3()'? was schreibe ich als kommentarzeile darüber? 'diese funktion darf nur von XXX aufgerufen werde und es gibt sie nur, weil sonst ein 'goto' in XXX wäre?

Das Problem hatte ich jetzt noch nie :). Aber ich verstehe schon, was du meinst oder meinen solltest.

Undertaker schrieb:

richtig, aber leider denken viele: 'um himmels willen, bloss kein goto in meinem programm!'. und vielleicht ist dieser djikstra daran schuld mit seinem artikel von anno dunnemals

Wenn ich mal (kommt selten vor) in Versuchung bin, goto zu verwenden, überlege ich erstmal fünf Minuten. Gar nicht unwahrscheinlich, dass ich dann erstmal umstrukturiere. Und das ist doch gut. (Stehe da ja nicht unter Zeitdruck ;))

.filmor

Undertaker schrieb:

aber ich würde es eher so sehen, dass das 'zerlegen in funktionen' der workaround ist und nicht die verwendung von 'goto'.
sinnvoll finde ich das 'aufräum und tschüss'-goto. das bekommt man natürlich auch dadurch weg, …

Mr. N schrieb:

Undertaker schrieb:

…

Klingt erstmal absurd. Begründe das doch bitte.

Xin schrieb:

sinnvoll finde ich das 'aufräum und tschüss'-goto.

Haha, schön wenn man klare Feindbilder hat

Mr. N

.filmor schrieb:

Haha, schön wenn man klare Feindbilder hat

Kannst du das nicht auch so ausdrücken, dass ichs gleich verstehe? Jetzt steht da wieder der richtige Name... :p