Ist goto ausnahmslos immer schlecht?

Shade Of Mine

hartmut1164 schrieb:

Wenn man natuerlich nicht in Recursionen denkt, hat man ein Problem.

ne ne ne. alles falsch.
rekursion ist ein tool das man benutzen kann und nicht etwas dass man auf alle probleme draufknallen muss.

Bashar

Ich denk eigentlich zuerst immer rekursiv, aber mit solchem furchtbaren Code ( if (foo == true) *schüttel*) möcht ich dann doch nichts zu tun haben

volkard

rekursion funktionierte in pascal, aber nicht in basic. also hat man geknallt, was das zeug hielt, um cool und wissenschaftlich zu sein.
uups, in c++ sehe ich einen ähnlichen effekt, was die verwendung von metaprogrammierung angeht. *angst*

ungarischer schrieb:

also zur unterscheidung von pointern und daten sollte man mindestens auf ungarische notation zurueckgreifen, was immer man bezüglich der namensgebung auch sonst noch treiben mag.

warum ausgerechnet bei pointern?

es ist meistens vorteilhaft, wenn man variablennamen halbwegs ansieht, was sie speichern

das zeigt mir jedes halbwegs moderne ide in aller ausführlichkeit an. und wenn du typen trotzdem falsch verwurstelst, sagt dir das der compiler.
ungarische notation erhöht den aufwand ohne echten nutzen.

rüdiger

Und Rekursion ist in C ja auch nicht ganz ungefährlich: http://damienkatz.net/2008/02/recursion_unsaf.html

volkard schrieb:

rekursion funktionierte in pascal, aber nicht in basic.

in basic geht's so in etwa: http://www.olympus.net/personal/7seas/recurse.html

pferdefreund

Je nach Sprache kann auch ein goto sinnvoll sein- natürlich nicht als
spaghetti - was ist den ein exec sql whenever.... - ist auch nur ein
goto oder
exec cics handle condition... ist auch ein goto
Wenn ich in eine Routine komme, und feststelle, hier brauch ich nix
zu tun, ist ein goto zum Routinenende sicherlich übersichtlicher wie
20 Klammern und 35 Ifs - ist so aus der mittlerweile 27-Jährigen
Programmentwicklung gewachsen.

Als ob irgendein Spacken hier die Weissheit mit Löffeln gefressen hätte und mir sagen darf was gut oder schlecht ist. Die Sprache stellt goto bereit. Jeder kann jetzt damit machen was er will.

volkard

dog-mom schrieb:

ungarischer schrieb:

also zur unterscheidung von pointern und daten sollte man mindestens auf ungarische notation zurueckgreifen, was immer man bezüglich der namensgebung auch sonst noch treiben mag.

warum ausgerechnet bei pointern?

weil man als anfänger nur bei pointern ohne jede compilerwarnung folgenden schweren fehler wiuederholt macht

while(a!=b) //statt while(*a!=*b)

ungarischer schrieb:

also zur unterscheidung von pointern und daten sollte man mindestens auf ungarische notation zurueckgreifen...

dann besser ausschreiben, also nicht sowas wie 'pRxPd' sondern 'RxPacketDescriptorPointer'. auch wenn's länglich wird, es macht den code verständlicher.

volkard

+fricky schrieb:

ungarischer schrieb:

also zur unterscheidung von pointern und daten sollte man mindestens auf ungarische notation zurueckgreifen...

dann besser ausschreiben, also nicht sowas wie 'pRxPd' sondern 'RxPacketDescriptorPointer'. auch wenn's länglich wird, es macht den code verständlicher.

einfach nur ein kleines p davor. also pPacketDescriptor istein pointer und PacketDescriptor ist ein kein pointer. das ist zwar schlimm, aber mir wird nicht übel davon.

Tachyon

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.

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.