was die goto s angeht:

Undertaker

gut schrieb:

jetzt haben wir wieder ein neues Thema, das "Methoden mit bool-Parametern und "Lesbarkeit" im Kontext" nervt ja auch schon.

ja, lasst uns anfangen
ich finde goto gut. es ist manchmal genz praktisch. leider gibt es programmiersprachen ohne goto (z.b. Java, aber Java hat als goto-ersatz 'labeled' break und continue statements).

rrtr schrieb:

Na SEH also ints geht glaube ich so:
__try
__except
__finally

Auf jeden fall nichts standardkonformes...

ach so, danke.

Also ich bevorzuge gotos, da diese deutlich schneller sein. Zudem verwende ich statt if-statements einfache subtraktion so wie es in assembelr der fall ist.

Auf diese Weise bin ich doppelt so schnell wie diese lahmen OOPler..

</spaß>

rüdiger

Undertaker schrieb:

sdfsdf schrieb:

Schau mal unter der Sektion "# Why don't we replace all the goto's with C exceptions?".

was sind denn 'C exceptions'?

vielleicht über setjmp. Aber in dem Beitrag steht ja etwas dazu.

rüdiger schrieb:

Undertaker schrieb:

sdfsdf schrieb:

Schau mal unter der Sektion "# Why don't we replace all the goto's with C exceptions?".

was sind denn 'C exceptions'?

vielleicht über setjmp. Aber in dem Beitrag steht ja etwas dazu.

Bestimmt so. 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

Undertaker

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

hustbaer

Wenn man modernes C++ (z.B. Verwendung von Exceptions, RAII, Guards) programmiert, braucht man IMO kein "goto" mehr, da sich sämtliche Fälle wo ich bis jetzt "goto" gebraucht habe anders (besser) lösen lassen.

Wenn man C programmiert ist "goto" z.B. praktisch um im Fehlerfall Cleanup-Code anzuspringen. Das Problem ist nicht "goto" grundsätzlich, sondern dass man damit viel Unfug treiben kann. z.B. nach oben springen, oder mitten in Scopes hinein. Solange man das bleiben lässt finde ich nicht allzuviel dabei -- viele Funktionen werden so viel übersichtlicher als ohne "goto".

Bashar

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

Mehr gibt es dazu nicht zu sagen.

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?