GOTO ist nicht langsam



  • gelöscht - doppelpost



  • GotoLover schrieb:

    troll28 schrieb:

    void foo()
    {
        for(a; ...)
        {
           while(c)
           {
              for(d; ...)
              {
                  if (e)
                     return;
              }
           }
        }
    }
    

    nicht foo, sondern

    ThisFuckingFunctionOnlyExistsBecauseIAmABloodyLamerWhoAvoidsGotoEvenIfItsUseful()
    

    Schon mal was von static gehört?



  • Irgendwer schrieb:

    Schon mal was von static gehört?

    static void ThisFuckingFunctionOnlyExistsBecauseIAmABloodyLamerWhoAvoidsGotoEvenIfItIsUseful()
    


  • Daniel E. schrieb:

    Walli schrieb:

    Noch besser als ein goto wäre es hier natürlich den inneren Code (falls sinnvoll trennbar) in eine Funktion auszulagern und sich den ganzen Mist zu schenken...

    Wobei unklar bleibt, ob es sinnvoll ist fünf returns in einer Hilfsfunktion zu halten; wenn man die Funktion nicht versteht, dann artet das auch in einem auf den ersten Blick verwirrenden Programmfluß aus wie bei goto.

    Genau deswegen schrieb ich ja "falls sinnvoll trennbar".

    Meist hilft es ein wenig über das gegebene Problem nachzudenken, wenn man seinen Code sauber strukturieren will. Und nachdenken heißt auch, nicht alles sofort zu verteufeln, bloß weil jemand vor zig Jahren mal was von "goto ist Böse" erzählt hat, dabei eigentlich aber ein ganz anderes goto als das in C meinte. Natürlich ist goto böse. Goto ist genauso böse wie Pointer, Casts und Makros. Mit fast allem kann man in C Blödsinn machen.
    Um das klarzustellen: Ich bin nicht der neue "Ritter des goto", aber diese Lehrbuch-Generalisierung "goto ist schlechter Stil" finde ich mindestens genauso bescheuert wie den unüberlegten Einsatz.
    Aber als Faustregel kann man IMO schon stehen lassen, dass sich jemand, der mehr als ein goto auf ~10000 LOC braucht Gedanken um seinen Stil machen sollte.



  • Da ich bei meine Code sehr viel mit hardwarenaher Steuerung und Messwerterfassung unter Echtzeitbedingungen zu tun habe, bin ich auch zwar der Auffassung das man auf das goto verzichten sollte so weit es irgendwie geht, es aber immer wieder Situationen gibt in dem das goto z.B. als Fehlerausprung mit dedizierter Fehlerbehandlung besser ist als multiple returns oder tonnenweise if´s mit if errorflag break.

    Das wichtigste ist ein klar strukturierter, gut lesbarer und wartbarer Algorithmus und Code. Wie dies erreicht wird ist nicht nur zweit sondern eher drittrangig.

    ➡ Um das Flamen noch ein bisschen anzuheizen:
    Selbst C++ kommt nicht ohne aus, es hat dem ganzen nur einen schöneren Namen gegeben Der Try - Throw - Catch ist nicht anderes als eine erweitertes und sehr viel leistungsfähigeres "goto" 🕶



  • PAD schrieb:

    Selbst C++ kommt nicht ohne aus, es hat dem ganzen nur einen schöneren Namen gegeben Der Try - Throw - Catch ist nicht anderes als eine erweitertes und sehr viel leistungsfähigeres "goto" 🕶

    in c heisst das 'longjmp' bzw. 'setjmp'. ansonsten 'full ack'



  • Nicht ganz 'longjmp' bzw. 'setjmp' springen quer durchs Programm ohne Rücksicht auf Stack,heap etc.

    Try - Throw - Catch geht durch die Routinen zurück und räumt auf. Mit einem goto zum routinenende und
    einem errorcode im returnwert könnte man ähnliches errichen.



  • goto ist einfach fix wie sau weils einfach zu nem unkonditionalen sprung wird. die loesungen ueber funktionsaufrufe sind nur dann genausoschnell wenn der compiler inlined, sonst hat man durch den call overhead. Und fuer komplizierte schleifenstrukturen oder um zum funktionsende also quasi clean_up_and_return: zu springen sieht man goto oft, und ich glaube nicht das diese verwendung schlecht ist (hier ist C,nicht C++), weil imo sowas kein spagetticode ist.



  • Naja, zum Spaghetticode brauchts ja mindestens 2 gotos. Lustigerweise schaffe ich es in den seltensten Fällen komplizierte Schleifenverschachtelungen zu bauen 🕶 .



  • @thomas001 fix wie sau ist nicht unbedingt das richtige Argument für goto´s, außer man muss mit realtime Bedingugen und/oder embedded Systemen umgehen und ist in der Nähe der Leistungsgrenzen des Systems.

    Modularer Code ist viel zu wichtig über die Lebenszeit eines Programms (10-15 Jahre) wegen der Wrtbarkeit das ich das ohne grund für Geschwindigkeit aufgeben würde.



  • @GotoLover
    Weist du auch was static bedeutet und wieso es hier Sinn macht?

    PAD schrieb:

    ➡ Um das Flamen noch ein bisschen anzuheizen:
    Selbst C++ kommt nicht ohne aus, es hat dem ganzen nur einen schöneren Namen gegeben Der Try - Throw - Catch ist nicht anderes als eine erweitertes und sehr viel leistungsfähigeres "goto" 🕶

    Das gleiche kann man von for, while und do while sagen. Allerdings sind die Schleifenkonstrukte eigentlich viel näher am goto als die C++ Ausnahmen.



  • Irgendwer schrieb:

    @GotoLover
    Weist du auch was static bedeutet und wieso es hier Sinn macht?

    Ich schätze du verwechselst das mit "inline"



  • GotoLover schrieb:

    Irgendwer schrieb:

    @GotoLover
    Weist du auch was static bedeutet und wieso es hier Sinn macht?

    Ich schätze du verwechselst das mit "inline"

    Nene. Guck mal:
    a.cpp

    static void loop(){}
    

    b.cpp

    static void loop(){}
    

    c.cpp

    static void loop(){}
    

    Wer sein Program in genügend Module aufteilt der braucht keine elendlangen Funktionsnamen. Einfach immer den gleichen benutzen. Was du jetzt mit inline willst weis ich jetzt nicht.



  • Irgendwer schrieb:

    Was du jetzt mit inline willst weis ich jetzt nicht.

    Den Funktionsaufruf wegmachen.
    PS: Ich bin "GotoLover", hab mich jetzt angemeldet



  • @Irgendwer

    Das gleiche kann man von for, while und do while sagen. Allerdings sind die Schleifenkonstrukte eigentlich viel näher am goto als die C++ Ausnahmen.

    Mag schon sein, bzw ist auch so das, die in Assembler als jmp ausgeführt werden. Aber ich glaubeh kaum das einer eines von diesen Konstrukten durch goto ersetzt.
    Der häufigste Anwendungsfall ist wohl das schlagartige Beenden eine tiefen Verschachtelung (zum Beispiel Fehler), um sich dieses bescheuerte

    if (error) 
     break;
    

    zum herauswühlen aus den Schleifen zu sparen.
    Und dies auch nur um konform zu irgendwelchen Standards zu sein, egal wie unübersichtlich das wird.



  • Sowas ähnliches wurde bestimmt schon genannt hier, GOTO ist gut um überflüssige Sachen auszulassen.

    ...
        void *p = malloc(...);
        if (aktion1(p) == ERROR) goto ende;
        if (aktion2(p) == ERROR) goto ende;
        if (aktion3(p) == ERROR) goto ende;
        if (aktion4(p) == ERROR) goto ende;
        aktion5(p);
    ende:
        free(p);
        ...
    


  • @Bug: das kannst du auch goto-frei haben:

    void *p = malloc(...);
    do
    {
        if (aktion1(p) == ERROR) break;
        if (aktion2(p) == ERROR) break;
        if (aktion3(p) == ERROR) break;
        if (aktion4(p) == ERROR) break;
        aktion5(p);
    } while(0);
    free(p);
    

    Nicht daß ich das für besser halte - aber die while-freaks freuen sich (hoffentlich 🤡 )

    @PAD: und vielleicht noch, um den Schleifeneintrittspunkt in die "Mitte" des Rumpfes legen. Ist so 'ne Angewohnheit aus Assembler-Zeiten.



  • Bug schrieb:

    Sowas ähnliches wurde bestimmt schon genannt hier, GOTO ist gut um überflüssige Sachen auszulassen.

    lol, du elendiger noob, lern erst einmal proggen und melde dich dann nochmal (also so in 10 jahren)



  • profiprogger schrieb:

    lern erst einmal proggen

    "PROGGEN" ???
    Das überlass ich lieber Blödbacken wie dir!


Anmelden zum Antworten