Ist goto ausnahmslos immer schlecht?

[hartmut1164]

DerKuchen schrieb:

hartmut1164 schrieb:

+fricky schrieb:

zu viele kreuz-und-quer sprünge in einer funktion können die lesbarkeit erschweren. ein geschickt platziertes goto kann den code sogar lesbarer machen. also, keine angst vor gotos. wenn's gut passt, immer rein damit.

Mit diesem Satz negierst Du bescheidene 40 Jahre strukutierte Programmierung.

Welche Version findest du besser?

A) ohne goto

Und jetzt stell dir mal vor, du musst in der Funktion auf einmal noch eine Datei öffnen, mehr Speicher allozieren oder sonst irgendwas machen, was hinterher aufgeräumt werden muss. In welcher Version kannst du einfacher und damit Fehlerresistenter den Aufräumbefehl einfügen?

z. B. so:

void funcA(size_t size)
{
    char     *buffer   = NULL;
    int       some_res = 0;
    FILE     *file     = NULL;
    int       err      = 0;

    buffer = malloc(sizeof (char) * size);
    if (buffer == NULL)
    {
        fprintf (stderr, "Can't alloc mem\n");
        err = 1;
    }
    else
    {
        some_res = get_sys_res(SOME_CONST);
        file = fopen("/the_life/the_universe/and/everything", "r");
        if (file == NULL)
        {
             fprintf (stderr, "Can't open file - details: Code <%d> Mssg: <%s>\n", 
                        errno, strerror (errno)");
             err = 1;
        }
    }

    if ((err                                  != 0) &&
        (do_something_with (some_res, buffer) != 0) &&
        (do_something_else (file, some_res)   != 0) &&
        (everything_ok     (buffer, file)     != 0))
               and_another_func(buffer, file, some_res);

    if (buffer != NULL) free   (buffer);
    if (file   != NULL) fclose (file  );
    free_sys_res(some_res);

    return;
}

Edit - einwenig vereinfacht

[supertux]

Also, ich finde die Version mit den gotos deutlich lesebarer und übersichtlicher. Und die Linux-Kernel Hacker ebenso, sie verwenden gotos vor allem bei Initialisieren von Modulen, da lernt man schon goto schätzen. Merke, goto macht keinen Code zum Spaghetti Code, sondern dessen Missbrauch.

[+fricky]

hartmut1164 schrieb:

Ich halte sogar das break- und continue-Statement in einem sauberen Programm bei Loops fuer nicht zu laessig, weil es eben ein verstecktes goto ist

das 'while' am ende einer do/while schleife ist auch ein verstecktes goto. oder das } am ende eines while- oder for-schleifenblocks, switch/case auch. du solltest die alle meiden, sind absolut böse gotos.

hartmut1164 schrieb:

NB: D. Knuth wurde damals ziemlich schnell von N. Wirth, von mindestens aehnlicher Reputation, widersprochen.

trotzdem hat wirth in sein pascal ein goto-statement eingebaut, der alte witzbold.

[dr. kniebrecher]

pauschalisierungen sind immer schlecht.

hartmut1164 schrieb:

Ich halte sogar das break- und continue-Statement in einem sauberen Programm bei Loops fuer nicht zu laessig, weil es eben ein verstecktes goto ist

aber wo liegt die grenze zwischen lässig und zu lässig?

+fricky schrieb:

das 'while' am ende einer do/while schleife ist auch ein verstecktes goto. oder das } am ende eines while- oder for-schleifenblocks, switch/case auch. du solltest die alle meiden, sind absolut böse gotos.

und erst der generierte maschinencode! der strotzt nur so von gotos, auch an stellen wo man es gar nicht erwartet!

[Bashar]

Grundler schrieb:

Jetzt hat ja goto eigentlich keinen guten Ruf (warum eigentlich?), aber ist das in diesem Fall ausnahmsweise ein sinnvoller Einsatz von 'goto', oder wie sonst könnte man das ohne 'goto' geschickter lösen (Es ist noch nicht vorherzusehen, wo überall beim Programmlauf Fehler auftreten könnten!)?

Ist das eine sehr strenge Regel, dass man kein goto verwenden darf, oder kann man da öftere Male eine Ausnahme von der Regel machen?

Lies "Go To Statement Considered Harmful" von Edsger Dijkstra und bilde dir deine eigene Meinung. Die meisten Leute kennen leider nur den Titel und nicht den Inhalt, geschweige denn die Argumentation, und verteufeln goto vollkommen.

Lies dann noch das Knuth-Paper, das hier verlinkt wurde.

Und wenn du das alles hast sacken lassen, besinne dich auf die Realität. Im echten Leben hat man meistens Vorgesetzte, die gut Dinge organisieren können (deshalb sind sie Vorgesetzte), aber von solchen philosophischen Details keine Ahnung haben, und dir ein goto negativ ankreiden werden. Der Kampf ist längst gefochten und verloren, goto wird sein Stigma nicht mehr los.

[hartmut1164]

+fricky schrieb:

hartmut1164 schrieb:

Ich halte sogar das break- und continue-Statement in einem sauberen Programm bei Loops fuer nicht zu laessig, weil es eben ein verstecktes goto ist

das 'while' am ende einer do/while schleife ist auch ein verstecktes goto. oder das } am ende eines while- oder for-schleifenblocks, switch/case auch. du solltest die alle meiden, sind absolut böse gotos.

Der Compiler setzt es in gotos um; aber wir reden ueber Hochsprachen-Code und hier sollten klare Verarbeitungs- und Ablaufbloecke gewahrt bleiben. Die Integritaet dieser Bloecke ist eben ein wesentlicher Bestandteil der strukturierten Programmierung.

+fricky schrieb:

hartmut1164 schrieb:

NB: D. Knuth wurde damals ziemlich schnell von N. Wirth, von mindestens aehnlicher Reputation, widersprochen.

trotzdem hat wirth in sein pascal ein goto-statement eingebaut, der alte witzbold.

Zumindest Modula-2 besitzt es nicht mehr (und glaube Modula-1 ebenfalls nicht).

[+fricky]

hartmut1164 schrieb:

+fricky schrieb:

hartmut1164 schrieb:

NB: D. Knuth wurde damals ziemlich schnell von N. Wirth, von mindestens aehnlicher Reputation, widersprochen.

trotzdem hat wirth in sein pascal ein goto-statement eingebaut, der alte witzbold.

Zumindest Modula-2 besitzt es nicht mehr (und glaube Modula-1 ebenfalls nicht).

und wie kommt man in modula aus, sagen wir mal, einer dreifach verschachtelten schleife raus, wenn sich im innern entscheidet, dass keine durchläufe (auch nicht der äusseren schleifen) mehr nötig sind? oder kann man in modula sowas gar nicht erst programmieren?

[sprunghaft]

Dass man jedes C-Programm theoretisch auch ohne goto schreiben kann, lasse ich mir einreden. Aber ich kann mir nicht vorstellen, dass das auch für break; oder continue; gilt (es sei denn, man würde Laufvariablen im Schleifenrumpf manipulieren wollen ...). Nicht für jede Schleife mit break; lässt sich eine äquivalente Schleife ohne break; erfinden.
Zumindest kann ich mir nicht vorstellen, dass das Gegenteil beweisbar wäre.

[_matze]

+fricky schrieb:

[...]sagen wir mal, einer dreifach verschachtelten schleife raus, wenn sich im innern entscheidet, dass keine durchläufe (auch nicht der äusseren schleifen) mehr nötig sind?

Das ist genau der Fall, wo ich auch gerne mal ein goto einsetze. Zuletzt (wohl auch der einzige Einsatz in Code, der zum Kunden ging) bei einer Hough-Transformation, bei der Schleifen 7- oder 8-fach verschachtelt waren. Warum sollte man in jede Schleife eine zusätzliche Abbsuchbedingung packen...

[volkard]

sprunghaft schrieb:

Dass man jedes C-Programm theoretisch auch ohne goto schreiben kann, lasse ich mir einreden. Aber ich kann mir nicht vorstellen, dass das auch für break; oder continue; gilt (es sei denn, man würde Laufvariablen im Schleifenrumpf manipulieren wollen ...). Nicht für jede Schleife mit break; lässt sich eine äquivalente Schleife ohne break; erfinden.
Zumindest kann ich mir nicht vorstellen, dass das Gegenteil beweisbar wäre.

scherzkeks. erstens ist return eh fast immer besser als break. und zweitens ist das verbot des rumfummelns an der laufbedingung der übliche weg, um aus dogmatischen erwägungen break zu umgehen. gerne mit while(i<anz && !fertig)

[+fricky]

sprunghaft schrieb:

Nicht für jede Schleife mit break; lässt sich eine äquivalente Schleife ohne break; erfinden.
Zumindest kann ich mir nicht vorstellen, dass das Gegenteil beweisbar wäre.

warum nicht? musst einfach nur in der schleife die abbruchbedingung gewaltsam herbeiführen, beispiel:

for (s=0; s<100; s++)
  {
    if (s == 10)
      s = 100;   // selbe wirkung wie 'break'
  }

[sprunghaft]

+fricky schrieb:

sprunghaft schrieb:

Nicht für jede Schleife mit break; lässt sich eine äquivalente Schleife ohne break; erfinden.
Zumindest kann ich mir nicht vorstellen, dass das Gegenteil beweisbar wäre.

warum nicht? musst einfach nur in der schleife die abbruchbedingung gewaltsam herbeiführen, beispiel:

for (s=0; s<100; s++)
  {
    if (s == 10)
      s = 100;   // selbe wirkung wie 'break'
  }

... und trotzdem muesste nach s = 100 noch continue; stehen. Es könnten nach der if(s == 10) Anweisung ja ohne weiteres noch zusätzliche Anweisungen in der Schleife stehen, von denen man plötzlich auf keinen Fall mehr möchte, dass sie ausgeführt werden.
Also nicht jede Schleife kann auch ohne break; bzw. continue; auskommen.
mfg

[+fricky]

sprunghaft schrieb:

... und trotzdem muesste nach s = 100 noch continue; stehen.

naja, nicht wenn beide zeilen die letzten im schleifenkörper sind.

[hartmut1164]

+fricky schrieb:

hartmut1164 schrieb:

+fricky schrieb:

hartmut1164 schrieb:

NB: D. Knuth wurde damals ziemlich schnell von N. Wirth, von mindestens aehnlicher Reputation, widersprochen.

trotzdem hat wirth in sein pascal ein goto-statement eingebaut, der alte witzbold.

Zumindest Modula-2 besitzt es nicht mehr (und glaube Modula-1 ebenfalls nicht).

und wie kommt man in modula aus, sagen wir mal, einer dreifach verschachtelten schleife raus, wenn sich im innern entscheidet, dass keine durchläufe (auch nicht der äusseren schleifen) mehr nötig sind? oder kann man in modula sowas gar nicht erst programmieren?

Durch setzen von Variablen (kein Modula - nur mal kurz reingeschnuppert vor Ewigkeiten, aber C):

bool Contains_5 (int    ***aDataCube,
                 int       iSize)
{
bool     fFound  = false;
int      iLoop_x = 0,
         iLoop_y,
         iLoop_z;

do
{
    iLoop_y = 0;
    do {
        iLoop_z = 0;
        {
            if (aDataCube [iLoop_x] [iLoop_y] [iLoop_z] == 5)
                fFound = true;
            else
                iLoop_z++;
        } while ((iLoop_z < iSize) && (fFound == false));

    iLoop_y++;
    } while ((iLoop_y < iSize) && (fFound == false));

    iLoop_x++;
} while ((iLoop_x < iSize) && (fFound == false));

return fFound;
}

In der "freien Wildbahn" wuerde ich das noch etwas bauen, aber es duerfte klar sein, wie das prinzip aussieht.

[hartmut1164]

_matze schrieb:

+fricky schrieb:

[...]sagen wir mal, einer dreifach verschachtelten schleife raus, wenn sich im innern entscheidet, dass keine durchläufe (auch nicht der äusseren schleifen) mehr nötig sind?

Das ist genau der Fall, wo ich auch gerne mal ein goto einsetze. Zuletzt (wohl auch der einzige Einsatz in Code, der zum Kunden ging) bei einer Hough-Transformation, bei der Schleifen 7- oder 8-fach verschachtelt waren. Warum sollte man in jede Schleife eine zusätzliche Abbsuchbedingung packen...

Der Algorithmus mag vielleicht mit achtfachen Schleifen arbeiten, aber man schneidet sich eher die rechte Hand ab als eine acht-fach geschachtelte Schleife wirklich so in Code zu schreiben. Im schlimmsten Falle muessen die Unterschleifen in eigene Funktionen gefasst werden.

[volkard]

hartmut1164 schrieb:

Der Algorithmus mag vielleicht mit achtfachen Schleifen arbeiten, aber man schneidet sich eher die rechte Hand ab als eine acht-fach geschachtelte Schleife wirklich so in Code zu schreiben. Im schlimmsten Falle muessen die Unterschleifen in eigene Funktionen gefasst werden.

und genau dann geht return eh viel besser als break!

[hartmut1164]

+fricky schrieb:

sprunghaft schrieb:

Nicht für jede Schleife mit break; lässt sich eine äquivalente Schleife ohne break; erfinden.
Zumindest kann ich mir nicht vorstellen, dass das Gegenteil beweisbar wäre.

warum nicht? musst einfach nur in der schleife die abbruchbedingung gewaltsam herbeiführen, beispiel:

for (s=0; s<100; s++)
  {
    if (s == 10)
      s = 100;   // selbe wirkung wie 'break'
  }

Das macht man eben nicht - ein for-Schleife wird dann verwendet, wenn man absolut sicher ist und unter allen Umstaenden, dass diese wirklich n-mal durchlaufen wird, ansonsten deklariert man eine Abbruchvariable, die die Schleife steuert.

[volkard]

hartmut1164 schrieb:

Das macht man eben nicht - ein for-Schleife wird dann verwendet, wenn man absolut sicher ist und unter allen Umstaenden, dass diese wirklich n-mal durchlaufen wird, ansonsten deklariert man eine Abbruchvariable, die die Schleife steuert.

falsch.

for(Node* pos=anchor;pos!=0;pos=pos->next)

aber ich gebe dir recht, daß man in c++ niemals an der laufvariablen rumfummelt. in basic hingegen tut man das dauernd machen. c ist ein bißchen dazwischen, fürchte ich.

[+fricky]

hartmut1164 schrieb:

In der "freien Wildbahn" wuerde ich das noch etwas bauen, aber es duerfte klar sein, wie das prinzip aussieht.

ja, finde ich total fürchterlich, jedesmal dieses flag abzufragen. allein schon, dass es 'fFound' und nicht einfach 'Found' heisst, würde mich aufregen.

hartmut1164 schrieb:

Das macht man eben nicht - ein for-Schleife wird dann verwendet, wenn man absolut sicher ist und unter allen Umstaenden, dass diese wirklich n-mal durchlaufen wird, ansonsten deklariert man eine Abbruchvariable, die die Schleife steuert.

dafür wirst du mich hassen, aber ich mache hin und wieder mal sowas:

for (;;)  // nicht 'while(1)', das mögen manche compiler nicht.
{
 ...
 if (...)
   break;
 ...
}

[+fricky]

volkard schrieb:

aber ich gebe dir recht, daß man in c++ niemals an der laufvariablen rumfummelt. in basic hingegen tut man das dauernd machen. c ist ein bißchen dazwischen, fürchte ich.

in C eigentlich auch nicht. das beispiel mit der for-schleife sollte nur zeigen, wie man ohne break rauskommt. in wirklichkeit würde ich sowas nie machen.