goto verwenden oder nicht?

Diese Frage mag klischeehaft klingen, aber ich bin hier in einer Situation.

Ich versuche, einen Finite-State-Automaten zu implementieren, um eine bestimmte Zeichenfolge in C zu analysieren. Als ich anfing, den Code zu schreiben, wurde mir klar, dass der Code möglicherweise besser lesbar ist, wenn ich Labels verwende, um die verschiedenen Zustände zu markieren, und goto verwende, um von einem Zustand zu springen ein anderes, wie der Fall kommt.

Die Verwendung der Standard-Breaks und Flag-Variablen ist in diesem Fall ziemlich umständlich und es ist schwierig, den Status zu verfolgen.

Welche Vorgehensweise ist besser? Mehr als alles andere mache ich mir Sorgen, dass es einen schlechten Eindruck bei meinem Chef hinterlassen könnte, da ich ein Praktikum mache.

Daran ist grundsätzlich nichts auszusetzen goto. Der Grund, warum sie oft als “Tabu” betrachtet werden, liegt in der Art und Weise, wie einige Programmierer (oft aus der Assembler-Welt kommend) sie verwenden, um “Spaghetti”-Code zu erstellen, der fast unmöglich zu verstehen ist. Wenn Sie verwenden können goto Anweisungen, während Sie Ihren Code sauber, lesbar und fehlerfrei halten, dann haben Sie mehr Leistung.

Verwenden goto Anweisungen und ein Codeabschnitt für jeden Zustand ist definitiv eine Möglichkeit, eine Zustandsmaschine zu schreiben. Die andere Methode besteht darin, eine Variable zu erstellen, die den aktuellen Status enthält, und eine switch-Anweisung (oder ähnliches) zu verwenden, um auszuwählen, welcher Codeblock basierend auf dem Wert der Statusvariablen ausgeführt werden soll. Siehe Aidan Cullys Antwort für eine gute Vorlage mit dieser zweiten Methode.

In Wirklichkeit sind sich die beiden Methoden sehr ähnlich. Wenn Sie einen Zustandsautomaten mit der State-Variable-Methode schreiben und kompilieren, kann die generierte Assembly Code sehr gut ähneln, der mit dem geschrieben wurde goto -Methode (abhängig vom Optimierungsgrad Ihres Compilers). Das goto -Methode kann als Optimieren der zusätzlichen Variable und Schleife aus der Zustandsvariablen-Methode angesehen werden. Welche Methode Sie verwenden, ist eine Frage der persönlichen Wahl, und solange Sie funktionierenden, lesbaren Code produzieren, würde ich hoffen, dass Ihr Chef nicht anders über Sie denkt, wenn Sie eine Methode gegenüber der anderen verwenden.

Wenn Sie diesen Code zu einer vorhandenen Codebasis hinzufügen, die bereits Zustandsmaschinen enthält, würde ich empfehlen, dass Sie der bereits verwendeten Konvention folgen.

Verwendung einer goto für die Implementierung einer Zustandsmaschine ist oft sinnvoll. Wenn Sie wirklich Bedenken haben, ein goto zu verwenden, ist es oft eine vernünftige Alternative, ein zu haben state Variable, die Sie ändern, und a switch darauf basierende aussage:

typedef enum {s0,s1,s2,s3,s4,...,sn,sexit} state;

state nextstate;
int done = 0;

nextstate = s0;  /* set up to start with the first state */
while(!done)
   switch(nextstate)
      {
         case s0:
            nextstate = do_state_0();
            break;
         case s1:
            nextstate = do_state_1();
            break;
         case s2:
            nextstate = do_state_2();
            break;
         case s3:
             .
             .
             .
             .
         case sn:
            nextstate = do_state_n();
            break;
         case sexit:
            done = TRUE;
            break;
         default:
            /*  some sort of unknown state */
            break;
      }

Ich würde einen FSM-Generator verwenden, wie Ragelwenn ich bei meinem Chef einen guten Eindruck hinterlassen wollte.

Der Hauptvorteil dieses Ansatzes besteht darin, dass Sie Ihren Zustandsautomaten auf einer höheren Abstraktionsebene beschreiben können und sich keine Gedanken darüber machen müssen, ob Sie goto oder einen Schalter verwenden. Ganz zu schweigen von dem besonderen Fall von Ragel, dass Sie automatisch schöne Diagramme Ihres FSM erhalten, Aktionen an jeder Stelle einfügen, die Anzahl der Zustände automatisch minimieren und verschiedene andere Vorteile haben können. Habe ich erwähnt, dass die generierten FSMs auch sehr schnell sind?

Die Nachteile sind, dass sie schwieriger zu debuggen sind (automatische Visualisierung hilft hier sehr) und dass Sie ein neues Tool lernen müssen (was sich wahrscheinlich nicht lohnt, wenn Sie eine einfache Maschine haben und wahrscheinlich nicht häufig Maschinen schreiben. )

Ich würde eine Variable verwenden, die nachverfolgt, in welchem ​​​​Zustand Sie sich befinden, und einen Schalter, um sie zu handhaben:

fsm_ctx_t ctx = ...;
state_t state = INITIAL_STATE;

while (state != DONE)
{
    switch (state)
    {
    case INITIAL_STATE:
    case SOME_STATE:
        state = handle_some_state(ctx)
        break;

    case OTHER_STATE:
        state = handle_other_state(ctx);
        break;
    }
}

Goto ist kein notwendiges Übel, und ich muss Denis stark widersprechen, ja, goto ist in den meisten Fällen eine schlechte Idee, aber es gibt Verwendungsmöglichkeiten. Die größte Angst bei goto ist der sogenannte “Spagetti-Code”, nicht nachvollziehbare Codepfade. Wenn man das vermeiden kann und immer klar ist, wie sich der Code verhält und man nicht mit einem goto aus der Funktion springt, spricht nichts gegen goto. Verwenden Sie es einfach mit Vorsicht, und wenn Sie versucht sind, es zu verwenden, bewerten Sie die Situation wirklich und finden Sie eine bessere Lösung. Wenn dies nicht möglich ist, kann goto verwendet werden.

Vermeiden goto es sei denn, die hinzugefügte Komplexität (zu vermeiden) ist verwirrender.

Bei praktischen technischen Problemen wird der Platz für goto sehr sparsam verwendet. Akademiker und Nicht-Ingenieure ringen unnötigerweise die Finger über die Verwendung goto. Das heißt, wenn Sie sich in eine Implementierungsecke malen, in der viele goto ist der einzige Ausweg, überdenken Sie die Lösung.

Eine korrekt funktionierende Lösung ist in der Regel das primäre Ziel. Richtig machen und wartbar (durch Minimierung der Komplexität) hat viele Lebenszyklusvorteile. Lassen Sie es zuerst funktionieren und reinigen Sie es dann nach und nach, vorzugsweise durch Vereinfachen und Entfernen von Hässlichkeit.

Ich kenne Ihren spezifischen Code nicht, aber gibt es einen Grund wie diesen:

typedef enum {
    STATE1, STATE2, STATE3
} myState_e;

void myFsm(void)
{
    myState_e State = STATE1;

    while(1)
    {
        switch(State)
        {
            case STATE1:
                State = STATE2;
                break;
            case STATE2:
                State = STATE3;
                break;
            case STATE3:
                State = STATE1;
                break;
        }
    }
}

würde nicht für dich funktionieren? Es nutzt nicht gotound ist relativ einfach zu folgen.

Bearbeiten: Alle diese State = Fragmente verletzen DRY, also könnte ich stattdessen so etwas tun:

typedef int (*myStateFn_t)(int OldState);

int myStateFn_Reset(int OldState, void *ObjP);
int myStateFn_Start(int OldState, void *ObjP);
int myStateFn_Process(int OldState, void *ObjP);

myStateFn_t myStateFns[] = {
#define MY_STATE_RESET 0
   myStateFn_Reset,
#define MY_STATE_START 1
   myStateFn_Start,
#define MY_STATE_PROCESS 2
   myStateFn_Process
}

int myStateFn_Reset(int OldState, void *ObjP)
{
    return shouldStart(ObjP) ? MY_STATE_START : MY_STATE_RESET;
}

int myStateFn_Start(int OldState, void *ObjP)
{
    resetState(ObjP);
    return MY_STATE_PROCESS;
}

int myStateFn_Process(int OldState, void *ObjP)
{
    return (process(ObjP) == DONE) ? MY_STATE_RESET : MY_STATE_PROCESS;
}

int stateValid(int StateFnSize, int State)
{
    return (State >= 0 && State < StateFnSize);
}

int stateFnRunOne(myStateFn_t StateFns, int StateFnSize, int State, void *ObjP)
{
    return StateFns[OldState])(State, ObjP);
}

void stateFnRun(myStateFn_t StateFns, int StateFnSize, int CurState, void *ObjP)
{
    int NextState;

    while(stateValid(CurState))
    {
        NextState = stateFnRunOne(StateFns, StateFnSize, CurState, ObjP);
        if(! stateValid(NextState))
            LOG_THIS(CurState, NextState);
        CurState = NextState;
    }
}

das ist natürlich viel länger als der erste Versuch (komische Sache mit DRY). Aber es ist auch robuster – wenn der Zustand nicht von einer der Zustandsfunktionen zurückgegeben wird, führt dies zu einer Compiler-Warnung, anstatt ein Fehlen stillschweigend zu ignorieren State = im früheren Code.