was die goto s angeht:

Undertaker schrieb:

Tim schrieb:

Ich habe mal einen Artikel gelesen, da haben die Entwickler einer embedded Anwendung Exceptions über setjmp usw. gebaut und waren deutlich schneller als das C++-Pendant (iirc ~Faktor 6-7). Den Link dazu find ich aber bestimmt nicht mehr

http://www.ddj.com/cpp/184404317
--> http://i.cmpnet.com/ddj/ddj/images/ddj0011i/0011it1.gif

Jo, ich glaub der war's. Wie ich auf die 6-7 komme weiss ich aber auch nicht mehr...

Hab ich den seinerzeit von dir... ermm... net?

Undertaker

Tim schrieb:

Jo, ich glaub der war's. Wie ich auf die 6-7 komme weiss ich aber auch nicht mehr...

du hast C++ leicht überschätzt. ~50 wäre richtig gewesen

Tim schrieb:

Hab ich den seinerzeit von dir... ermm... net?

wär' schon möglich, weiss ich aber nicht mehr.

Mr. N

Undertaker schrieb:

Tim schrieb:

Jo, ich glaub der war's. Wie ich auf die 6-7 komme weiss ich aber auch nicht mehr...

du hast C++ leicht überschätzt. ~50 wäre richtig gewesen

Hast du das gemessen? Ist dir bewusst, dass C++ absichtlich nicht einfach setjmp für Exceptions benutzt?

@Tim: Was hast du angerichtet?!

Undertaker

Mr. N schrieb:

Hast du das gemessen?

nö, aber ich glaub DDJ kann man vertrauen

Mr. N schrieb:

Ist dir bewusst, dass C++ absichtlich nicht einfach setjmp für Exceptions benutzt?

kann ich mir denken. C++ muss ja für exceptions irgendwelche objekte durch die gegend schubsen.

asdasdas schrieb:

Java is eh besser als C++.

in Java sind exceptions auch lahm.

Mr. N

Undertaker schrieb:

Mr. N schrieb:

Ist dir bewusst, dass C++ absichtlich nicht einfach setjmp für Exceptions benutzt?

kann ich mir denken. C++ muss ja für exceptions irgendwelche objekte durch die gegend schubsen.

Vor allem aber muss C++ Stack-Unwinding betreiben, und für jeden einzelnen Frame überprüfen ob Destruktoren oder catch-Blöcke auszuführen sind. Da Exceptions, wie der Name schon sagt, selten geworfen werden und das Ausführen der Destruktoren an der Stelle enorm praktisch ist, stört das aber eigentlich keinen.

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

Edit: Sorry, aber der musste einfach sein

Undertaker

Mr. N schrieb:

Da Exceptions, wie der Name schon sagt, selten geworfen werden und das Ausführen der Destruktoren an der Stelle enorm praktisch ist, stört das aber eigentlich keinen.

es wirkte sich aber immer negativ auf die code-grösse aus (siehe tabelle)
--> http://i.cmpnet.com/ddj/ddj/images/ddj0011i/0011it1.gif
aus diesem grund lässt sich wohl das exception handling bei vielen C++ compilern disablen.

Tim schrieb:

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

netter vergleich

It is like butchers banning knives because workers sometimes cut themselves.

...und der knuth ist ja auch nicht gerade der dümmste:
--> http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf

Bashar

Tim schrieb:

Edit: Sorry, aber der musste einfach sein

Tim, genau aus dem Grund habe ich den Artikel verlinkt und nicht einfach nur den Titel genannt. In deinem Artikel steht überhaupt nichts zum eigentlichen Inhalt von Dijkstras Artikel, er hängt sich sehr an der -- zugegeben reißerischen -- Überschrift auf. Dabei ist die Begründung der Feststellung aus dem Titel sehr erhellend und wesentlich informativer als alle 23568972 Foren-Flameschlachten, die je dazu gefochten wurden. Sozusagen ist dein Artikel eine Bestätigung. Irgendwas böse zu finden ist vollkommen unsinnig, man muss auch wissen wieso.

Bashar schrieb:

...

Schon klar. Aber ich finde den Titel so doll und konnte einfach nicht widerstehen

Undertaker

Bashar schrieb:

Irgendwas böse zu finden ist vollkommen unsinnig, man muss auch wissen wieso.

man kann's aber auch übertreiben:

I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code)

naja, 1968 ist lange her, da haben noch viele mit'm hexeditor maschinencodes reingehackt.

Mr. N

Undertaker schrieb:

Mr. N schrieb:

Da Exceptions, wie der Name schon sagt, selten geworfen werden und das Ausführen der Destruktoren an der Stelle enorm praktisch ist, stört das aber eigentlich keinen.

es wirkte sich aber immer negativ auf die code-grösse aus (siehe tabelle)
--> http://i.cmpnet.com/ddj/ddj/images/ddj0011i/0011it1.gif

35 KB - im Ernst, bei größeren Projekten entsteht dann natürlich immer noch eine Code-Vergrößerung aber proportional gesehen wesentlich weniger.

Undertaker schrieb:

aus diesem grund lässt sich wohl das exception handling bei vielen C++ compilern disablen.

Oder weil man z.B. in einer Umgebung ohne Runtime compiliert. Aber allermeistens sollte man Exceptions anlassen.

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