was die goto s angeht:



  • Linus Torvalds schrieb:
    So switching to if-then-else blocks might be good Computer Science theory, but using goto's is good Engineering.





  • Also in der Quelle steht nicht, dass Linus Torvalds das geschrieben hat. Wobei ich mir sicher bin, dass er das so unterschreiben würde.



  • Tim schrieb:

    Also in der Quelle steht nicht, dass Linus Torvalds das geschrieben hat. Wobei ich mir sicher bin, dass er das so unterschreiben würde.

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

    Oder suchste darin den namen von Linus Torvalds? AFAIK sind das Auszüge aus Mailinglisten oder ähnlichem. Auf den link bin ich eben gestoßen, als ich über die Äußerungen von L.T. was lesen wollte.



  • Der Satz ist totaler Käse. if-then ist gute Praxis, für die Theorie tuts auch goto oder lambda oder jegliches hinreichend mächtige Kontrollflußkonstrukt.



  • lkml = linux kernel mailing list



  • sdfsdf schrieb:

    Tim schrieb:

    Also in der Quelle steht nicht, dass Linus Torvalds das geschrieben hat. Wobei ich mir sicher bin, dass er das so unterschreiben würde.

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

    Oder suchste darin den namen von Linus Torvalds? AFAIK sind das Auszüge aus Mailinglisten oder ähnlichem. Auf den link bin ich eben gestoßen, als ich über die Äußerungen von L.T. was lesen wollte.

    http://www.tux.org/lkml/#s15-5

    Also da steht doch eindeutig REG davor, oder? Und selbigem Link entnehme ich, dass sich dahinter ein gewisser Richard E. Gooch versteckt.



  • Bashar schrieb:

    Der Satz ist totaler Käse. if-then ist gute Praxis, für die Theorie tuts auch goto oder lambda oder jegliches hinreichend mächtige Kontrollflußkonstrukt.

    Ich glaube kaum, dass du über genügend Theorie- und Praxiserfahrung verfügst, dass du die oben genannte Aussage von Linus in Frage stellen könntest. Nichts persönliches, aber ich finde gotos auch nicht sooo schlimm, auch wenn ich trotzdem gotos meist versuche zu vermeiden.

    ps: Lies mal die gesamte mailinglist, also den link den ich oben gepostet hab. sind noch ein paar andere faktoren zu berücksichtigen.



  • @Tim: UUUups! Ich bin über eine andere Seite darauf gestoßen. Und auf der anderen Seite wurde auf diese mailinglist verlinkt mit dem kommentar, dasses von Linus wäre. Sorry,



  • Das war nicht Linus. Der Author steht doch in den Klammern: REG: Richard E. Gooch (FAQ maintainer) 🙄



  • sdfsdf schrieb:

    Ich glaube kaum, dass du über genügend Theorie- und Praxiserfahrung verfügst, dass du die oben genannte Aussage von Linus in Frage stellen könntest. Nichts persönliches, aber ich finde gotos auch nicht sooo schlimm, auch wenn ich trotzdem gotos meist versuche zu vermeiden.

    Ja klar, Linus ist Gott, schon klar. *verbeug*

    ps: Lies mal die gesamte mailinglist, also den link den ich oben gepostet hab. sind noch ein paar andere faktoren zu berücksichtigen.

    Der Satz mag im Kontext seine Berechtigung haben, so allein stehend ist er aber Quatsch. Eignet sich nicht als Signatur. BTW lies doch mal meine gesamten Postings hier um meine Meinung über gotos zu erfahren.



  • sdfsdf schrieb:

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

    was sind denn 'C exceptions'?



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

    Auf jeden fall nichts standardkonformes...



  • 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ß>



  • 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 😉



  • 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
    🙂



  • 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".



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

    Mehr gibt es dazu nicht zu sagen.


Anmelden zum Antworten