Ist goto ausnahmslos immer schlecht?

volkard

Tachyon schrieb:

Nichts für ungut, aber wie man seine Bezeichnet wählt, sollte jedem selbst überlassen bleiben, sofern man in sich konsistent bleibt und es keine Richtlinie gibt, die konkrete Vorgaben machen.

auf gar keinen fall. sonst kommt die gedankenpolizei und justiert den persönlichen geschmack neu.

+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 wieso sollte das besser sein?
schließlich musst du beim lesen des codes immernoch die Zeile "if(s==10)" lesen, dann sehen dass "s = 100" einen abbruch bzw eine beendigung der schleife bedeutet, was umständlicher ist als ein einfaches "break", da man sich noch die Abbruchbedingung merken muss(zugegebenerweise im allgemeinen leicht zu merken).
Break ist ein offensichtlicher Abbruch, deine Variante hingegen ein "verdeckter"

kingcools2 schrieb:

und wieso sollte das besser sein?

es ist nicht besser, aber irgendwer hier hatte was gegen break und continue in schleifen.

hartmut1164

+fricky schrieb:

kingcools2 schrieb:

und wieso sollte das besser sein?

es ist nicht besser, aber irgendwer hier hatte was gegen break und continue in schleifen.

Ja - weil es klare Abbruchbedingungen versteckt. Die Codition der Durchfuehrung einer Schleife sollte nur einmal definiert sein und nicht an verschiedenen Orten. Ist halt wieder ein hidden-goto.

hartmut1164 schrieb:

Die Codition der Durchfuehrung einer Schleife sollte nur einmal definiert sein und nicht an verschiedenen Orten. Ist halt wieder ein hidden-goto.

lass mich raten - du findest es bestimmt auch doof, wenn mehr als ein 'return' aus einer funktion herausführen, oder?

hartmut1164

+fricky schrieb:

hartmut1164 schrieb:

Die Codition der Durchfuehrung einer Schleife sollte nur einmal definiert sein und nicht an verschiedenen Orten. Ist halt wieder ein hidden-goto.

lass mich raten - du findest es bestimmt auch doof, wenn mehr als ein 'return' aus einer funktion herausführen, oder?

In den allermeisten Faellen ja. Ich kenne nur zwei Faelle wo man das guten Gewissen machen kann:

Bei Recursiven Funktionen ist oft nicht zu vermeiden (um saubere Abbruchbedingungen zu haben ohne mit localen Variabken den Stack mehr belasten als ohnehin schon).
Wenn sich diese zum Ende der Funktion als eine Einheit darstellen.

Ansonsten hat ein return mitten in einer Funktion nichts zu suchen.

Tachyon

hartmut1164 schrieb:

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;
}

Und was ist, wenn noch 5 weitere Ressourcen benötigt werden, und nicht nur drei? Bei dieser Version geht geht die Übersicht bereits komplett flöten.
Mal davon abgesehen, wird im Fall err != 0 munter do_something_with (some_res, buffer) aufgerufen, und das kann zu nichts Gutem führen, selbst wenn Du den Rückgabewert auswertest. Mit goto wär das nicht passiert.

supertux

Also, ich denke entweder ist hartmut ein codetaliban/fundamentalist oder er will uns nur verarschen. Selber schuld, wer sich seinen Code aus fundamentalistischen Gründen unleserlich und unwartbar macht.

_matze

hartmut1164 schrieb:

Ansonsten hat ein return mitten in einer Funktion nichts zu suchen.

Das hat mir mein Ausbilder auch noch beigebracht. Genauso wie man alle Variablen am Anfang einer Funktion deklarieren soll, globale Variablen praktisch sind und intensiv genutzt werden sollten, Funktionen ruhig mal eine drei- oder vierstellige Zeilenanzahl erreichen dürfen, usw...

hartmut1164

Tachyon schrieb:

Und was ist, wenn noch 5 weitere Ressourcen benötigt werden, und nicht nur drei?

Diese werden auf dem Stack alloiert und gleich wieder freigeben; das ist nur ein Problem bei extensiven Rekursionen (oder im embedded-Bereich). Wenn die Vairablenliste groesser als 5 oder 6 wird, sollte man sich das Design der Funktion noch ueberlegen; dann wird einfach zuviel Funktionalitaet hineingeschmiert.

Das gleich gilt fuer die Laenge: Eine Funktion sollte eine Bildschirmseite nicht ueberschreiten.

Tachyon schrieb:

Mal davon abgesehen, wird im Fall err != 0 munter do_something_with (some_res, buffer) aufgerufen, und das kann zu nichts Gutem führen, selbst wenn Du den Rückgabewert auswertest.

Das tut er nicht: --> Sequence Point, C99-Std, Annex C und 6.5.13. - War auch Std. in den ersten Entwuerfen zu C in den fruehen 1970ern, bin aber zu faul das rauszusuchen.

Tachyon

hartmut1164 schrieb:

Wenn die Vairablenliste groesser als 5 oder 6 wird, sollte man sich das Design der Funktion noch ueberlegen; dann wird einfach zuviel Funktionalitaet hineingeschmiert.

Das ist Quark. Viele Ressourcen zu allokieren bedeutet nicht, viel Funktionalität zu haben.

hartmut1164 schrieb:

Das tut er nicht: --> Sequence Point, C99-Std, Annex C und 6.5.13. - War auch Std. in den ersten Entwuerfen zu C in den fruehen 1970ern, bin aber zu faul das rauszusuchen.

Klar tut er das. Short Circuit Evaluation ist Dir ein Begriff?

Bashar

Tachyon schrieb:

Klar tut er das. Short Circuit Evaluation ist Dir ein Begriff?

In Pascal gibts das nicht

hartmut1164

Tachyon schrieb:

hartmut1164 schrieb:

Das tut er nicht: --> Sequence Point, C99-Std, Annex C und 6.5.13. - War auch Std. in den ersten Entwuerfen zu C in den fruehen 1970ern, bin aber zu faul das rauszusuchen.

Klar tut er das. Short Circuit Evaluation ist Dir ein Begriff?

6.5.13

4 Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation;
there is a sequence point after the evaluation of the first operand. If the first operand
compares equal to 0, the second operand is not evaluated.

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf

---

"Short circuit evalution" bedeutet, dass die nachfolgende (Teil-)Expression nicht mehr ausgewertet wird, wenn die erste (Teil-)Expression schon den Wert der Gesamtexpression determiniert. Das ist bei der &&-Sequence der Fall, da ein logisches "False" die Gesamtexpression zu "False" werden laesst.

Also hier:

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

Wenn also (err != 0) ist, wird do_something etc. nicht ausgefuehrt, da es den Gesamtwert nicht mehr veraendern kann; entsprechend der Reihenfolge festgelegt in 6.5.13 der ISO9899.

hartmut1164

Bashar schrieb:

Tachyon schrieb:

Klar tut er das. Short Circuit Evaluation ist Dir ein Begriff?

In Pascal gibts das nicht

Doch gibt es das in Pascal. C und Pascal benutzen hier aehnliche Techniken.

volkard

hartmut1164 schrieb:

Bashar schrieb:

Tachyon schrieb:

Klar tut er das. Short Circuit Evaluation ist Dir ein Begriff?

In Pascal gibts das nicht

Doch gibt es das in Pascal. C und Pascal benutzen hier aehnliche Techniken.

zeig mal nen link, der das bestätigt.
nee, habs selber gefunden.

Bashar

Der Link würde mich ja dann doch mal interessieren. Meines Wissens spezifiziert Pascal keine Shortcut-Semantik. In Turbo Pascal kann man es ein oder ausschalten, aber ich rede nicht von Turbo Pascal.

Tachyon

hartmut1164 schrieb:

...rhabarber...

Und was kommt Deiner Meinung nach bei err = 1 (Fehler) und err != 0 für ein Wahrheitswert heraus?

hartmut1164 schrieb:

6.5.13

4 Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation;
there is a sequence point after the evaluation of the first operand. If the first operand
compares equal to 0, the second operand is not evaluated.

Du sagst es.

hartmut1164

Bashar schrieb:

Der Link würde mich ja dann doch mal interessieren. Meines Wissens spezifiziert Pascal keine Shortcut-Semantik. In Turbo Pascal kann man es ein oder ausschalten, aber ich rede nicht von Turbo Pascal.

Es abhaenig von Umgebung - Ich habe nochmal nachgeschaut; Der Annex F der ISO7185 listet die Faelle in der dies durch Implementation definiert wird. Die Technik ist die selbe, nur u.U. "verkehrt" herum. Was natuerlich nicht befriedigend ist.

volkard

Bashar schrieb:

Der Link würde mich ja dann doch mal interessieren. Meines Wissens spezifiziert Pascal keine Shortcut-Semantik. In Turbo Pascal kann man es ein oder ausschalten, aber ich rede nicht von Turbo Pascal.

standard-pascal läßt es offen
http://www.soe.ucsc.edu/classes/cmps203/Spring98/hw/example2.html

Die „Short Circuit“-Funktionalität von && und || in C (sobald das Ergebnis feststeht, nämlich wenn der linke Teil beim and FALSE beziehungsweise beim or TRUE ist, wird der rechte nicht mehr ausgewertet) schloss N. Wirth explizit aus
http://de.wikipedia.org/wiki/Pascal_(Programmiersprache)

GNU Pascal machts aber by default
http://www.mirrorservice.org/sites/www.gnu-pascal.de/gpc/and.html

hartmut1164

Tachyon schrieb:

hartmut1164 schrieb:

...rhabarber...

Und was kommt Deiner Meinung nach bei err = 1 (Fehler) und err != 0 für ein Wahrheitswert heraus?

The == (equal to) and != (not equal to) operators are analogous to the relational
operators except for their lower precedence.93) Each of the operators yields 1 if the
specified relation is true and 0 if it is false. The result has type int. For any pair of
operands, exactly one of the relations is true.

CC99, 6.5.9.4 Equality operators, URL. s.o.