Die verpönten goto´s

berniebutt schrieb:

Ja, manchmal ist ein goto zwingend

Nö.

berniebutt schrieb:

oder die beste Wahl.

Finde ich auch.

berniebutt schrieb:

Anderenfalls hätte man diese Möglichkeit abschaffen können. Einsatz selten, dann aber sauber und gut kommentiert!
daddeldu

Oder wenn du eine Assembler-Routine aus TAOCP schnell mal abschreiben willst.

volkard

Oft lagert man aus, und geht dabei davon aus, daß der Compiler die Mini-Funktion wieder einlagert. (Aber ein 2d-Array durchsuchen, das ist doch schon ein Brocken von mehreren tausen Takten, da sollte der Funktionsaufruf nicht mehr ins Gewicht fallen.) Damit ist es nicht mehr so extrem wichtig, wie die Übergabe geschieht, ob über Zeiger oder so. Eigentlich bleiben es ja die beiden Variablen in der äußeren Funktion und eigentlich bleibt die Schleife drinnen, nur darfst Du die Suchfunktion woanders ausfiormulierenm.

volkard schrieb:

Aber ein 2d-Array durchsuchen, das ist doch schon ein Brocken von mehreren tausen Takten, da sollte der Funktionsaufruf nicht mehr ins Gewicht fallen.

Das Inlining kannst du ja auch einfach befehlen. Dann bleibt als Overhead nur mehr die Prüfung der Rückgabe, oder?

volkard

µngbd schrieb:

volkard schrieb:

Aber ein 2d-Array durchsuchen, das ist doch schon ein Brocken von mehreren tausen Takten, da sollte der Funktionsaufruf nicht mehr ins Gewicht fallen.

Das Inlining kannst du ja auch einfach befehlen. Dann bleibt als Overhead nur mehr die Prüfung der Rückgabe, oder?

Ja. Aber da geinlined, sieht der Optimierer wohl die Nutzlosigkeit einer Hilfsvariablen ein und macht den goto-Trick oder was ähnliches. Also nicht erst die Rückgabe in eine Variable tun.

earli

Kurze Faustregel:

Goto nach vorn ist okay (wenn keine Alternative einfacher ist), goto zurück ist böse.

earli schrieb:

Kurze Faustregel:
Goto nach vorn ist okay (wenn keine Alternative einfacher ist), goto zurück ist böse.

Goto ist dann OK, wenn es die Lesbarkeit des Codes verbessert, oder zumindest nicht verschlechtert.

earli

schpätli schrieb:

earli schrieb:

Kurze Faustregel:
Goto nach vorn ist okay (wenn keine Alternative einfacher ist), goto zurück ist böse.

Goto ist dann OK, wenn es die Lesbarkeit des Codes verbessert, oder zumindest nicht verschlechtert.

Deine Regel lässt sich einfach hinschreiben, aber überhaupt nicht umsetzen.

Toller Satz: "Goto ist dann lesbarer, wenn es den Code lesbarer macht."
> http://xkcd.com/703/

volkard

earli schrieb:

schpätli schrieb:

earli schrieb:

Kurze Faustregel:
Goto nach vorn ist okay (wenn keine Alternative einfacher ist), goto zurück ist böse.

Goto ist dann OK, wenn es die Lesbarkeit des Codes verbessert, oder zumindest nicht verschlechtert.

Deine Regel lässt sich einfach hinschreiben, aber überhaupt nicht umsetzen.

Toller Satz: "Goto ist dann lesbarer, wenn es den Code lesbarer macht."
> http://xkcd.com/703/

Ist nur Deine eigene Regel (Goto rückwärts ist eh indiskutablel):
"Goto ist okay, wenn keine Alternative einfacher ist."

earli schrieb:

Toller Satz: "Goto ist dann lesbarer, wenn es den Code lesbarer macht."
> http://xkcd.com/703/

Ich habe das nicht geschrieben?

Lesbarkeit: | Schlecher | Gleich | Besser
------------------------------------------
Goto OK?:   |   Nein    |  Ja    |  Ja

Komplexität: | Höher | Gleich | Geringer
----------------------------------------
Goto OK?:    | Nein  |  Nein  |  Ja

while(1){
  status = recv(new_socket_fd, msg, sizeof(msg),0 );
  if(status > 0){
    readPtr(msg,status);
    continue;
  }else if( status == 0){
  }else{
    //status < 0
  }
  break;
}

loop:
  status = recv(new_socket_fd, msg, sizeof(msg),0 );
  if(status > 0){
    readPtr(msg,status);
    goto loop;
  }else if( status == 0){
  }else{
    //status < 0
  }

bedeutet für mich 18,2% bzw. 12,5% weniger Einkommen nach dem klassischen Cocomo Model, eigentlich habt ihr ja Recht, man soll sich nicht selbst ins Knie schießen

lg lolo

do{
  status = recv(new_socket_fd, msg, sizeof(msg),0 );
  if(status > 0){
    readPtr(msg,status);
  }else if( status == 0){
  }else{
    //status < 0
  }
}while(status > 0);

sowas lässt den vorteil der goto variante verschwinden, man müßte mal testen, ob der compiler die while condition verschwinden lässt, wenn ja könnt ich mich damit schon anfreunden

knivil

aber das goto ist in dem Fall ganz in Ordnung ... manchmal ist ein goto zwingend oder die beste Wahl ... Goto nach vorn ist okay ... Goto ist okay, wenn keine Alternative einfacher ist.

Ich habe noch nie ein goto fuer noetig gehalten. Es gab immer eine bessere Alternative.

Damit wurde in früheren Zeiten schrecklicher Spaghetti-Code erzeugt.

Um Spaghetti-Code zu erzeugen, braucht es kein goto. Lambda, the ultimate GOTO

Die Frage ist nicht, ob gotos in diesem Fall in Ordnung sind, sondern ob der dargestellte Code eher an Spaghettis erinnert. Das tut er. Vorschlaege fuer Verbesserungen wurden bereits gemacht.

rüdiger

knivil schrieb:

aber das goto ist in dem Fall ganz in Ordnung ... manchmal ist ein goto zwingend oder die beste Wahl ... Goto nach vorn ist okay ... Goto ist okay, wenn keine Alternative einfacher ist.

Ich habe noch nie ein goto fuer noetig gehalten. Es gab immer eine bessere Alternative.

Bei der Fehlerbehandlung sind die in C oft praktisch

void foo() {
  allocateX();
  allocateY();

  if(!a())
    goto cleanup;

  if(!b())
    goto cleanup;

  c();

cleanup:
  freeX();
  freeY();
}

FlashBurn

Genau für solche Fehlerbehandlung, wo Code doppelt und dreifach vorhanden ist, nutze ich auch die goto´s!

earli

schpätli schrieb:

earli schrieb:

Toller Satz: "Goto ist dann lesbarer, wenn es den Code lesbarer macht."
> http://xkcd.com/703/

Ich habe das nicht geschrieben?
Lesbarkeit: | Schlecher | Gleich | Besser
------------------------------------------
Goto OK?:   |   Nein    |  Ja    |  Ja
Komplexität: | Höher | Gleich | Geringer
----------------------------------------
Goto OK?:    | Nein  |  Nein  |  Ja

Mein Punkt ist, dass man beides nicht messen kann. Meine Regel sollte ja auch nur eine "Faustregel" sein. Und als solche ist sie klar anwendbar.

earli schrieb:

Mein Punkt ist, dass man beides nicht messen kann.

Eine Abschätzung reicht.

earli schrieb:

Meine Regel sollte ja auch nur eine "Faustregel" sein. Und als solche ist sie klar anwendbar.

Mit Deiner Regel kannst Du Dir den Hintern abwischen.

earli

rüdiger schrieb:

knivil schrieb:

aber das goto ist in dem Fall ganz in Ordnung ... manchmal ist ein goto zwingend oder die beste Wahl ... Goto nach vorn ist okay ... Goto ist okay, wenn keine Alternative einfacher ist.

Ich habe noch nie ein goto fuer noetig gehalten. Es gab immer eine bessere Alternative.

Bei der Fehlerbehandlung sind die in C oft praktisch
void foo() {
  allocateX();
  allocateY();

  if(!a())
    goto cleanup;

  if(!b())
    goto cleanup;

  c();

cleanup:
  freeX();
  freeY();
}

Kein gutes Beispiel, da einfacher:

void foo() {
  allocateX();
  allocateY();

  if(a() && b())
    c();

  freeX();
  freeY();
}

earli

schpätli schrieb:

earli schrieb:

Mein Punkt ist, dass man beides nicht messen kann.

Eine Abschätzung reicht.

Das ist doch gar nicht das Problem. Lesbarkeit ist einfach sehr subjektiv. Und wenn in einer großen Gruppe von Programmierern (zum Beispiel bei Linux -- wo goto unabdingbar ist, da ständig viele Locks auf Ressourcen angelegt und aufgehoben werden -- kamen Patches von über 2000 Personen im Jahr 2009) keine klare Regel angibst, hast du einfach verkackt.

earli schrieb:

Kein gutes Beispiel, da einfacher:

void foo() 
{
  allocateX();
  allocateY();

  if(a() && b())
    c();

  freeX();
  freeY();
}

void foo (void)  // hier gehört "void" in die Klammer
{
  allocateX();
  allocateY();

  if (...)
  {
     for(...)
     {
        while (...)
        {
            do(...)
            {
                if (error) goto exit;
            }
        }
     }
  }
  c();

exit:
  freeX();
  freeY();
}

earli schrieb:

Lesbarkeit ist einfach sehr subjektiv.

Eigentlich nicht, das ist wie mit gutem Geschmack, der ist bei vielen gleich und nur wenige unterscheiden sich davon.

Es mag Menschen geben, die empfinden Source http://www.de.ioccc.org/years.html dieses Types als leserlich, aber der Prozentsatz ist doch relativ klein