Использовать goto или нет?

Использование goto для реализации конечного автомата часто имеет смысл. Если вас действительно беспокоит использование goto, разумной альтернативой часто является state переменная, которую вы изменяете, и основанный на ней оператор switch:

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

В goto нет ничего плохого. Причина, по которой они часто считаются «табу», заключается в том, что некоторые программисты (часто из мира сборки) используют их для создания «спагетти» кода, который практически невозможно понять. Если вы можете использовать операторы goto, сохраняя при этом ваш код чистым, читаемым и без ошибок, тогда вам будет больше возможностей.

Использование операторов goto и раздела кода для каждого состояния определенно является одним из способов написания конечного автомата. Другой метод - создать переменную, которая будет содержать текущее состояние, и использовать оператор switch (или аналогичный), чтобы выбрать, какой блок кода выполнить, на основе значения переменной состояния. См. Ответ Эйдана Калли, чтобы узнать о хорошем шаблоне, использующем этот второй метод.

На самом деле эти два метода очень похожи. Если вы напишете конечный автомат с использованием метода переменной состояния и скомпилируете его, сгенерированная сборка может очень напоминать код, написанный с использованием метода goto (в зависимости от уровня оптимизации вашего компилятора). Метод goto можно рассматривать как оптимизацию дополнительной переменной и цикла из метода переменной состояния. Какой метод вы используете, зависит от вашего личного выбора, и пока вы создаете рабочий, читаемый код, я надеюсь, что ваш начальник не подумает о вас по-другому из-за того, что вы используете один метод по сравнению с другим.

Если вы добавляете этот код в существующую базу кода, которая уже содержит конечные автоматы, я бы рекомендовал вам следовать тому соглашению, которое уже используется.

Я бы использовал генератор FSM, например Ragel, если бы я хотел произвести хорошее впечатление босс.

Основное преимущество этого подхода заключается в том, что вы можете описать конечный автомат на более высоком уровне абстракции и вам не нужно беспокоиться о том, использовать ли goto или переключатель. Не говоря уже о том, что в конкретном случае Ragel вы можете автоматически получать красивые диаграммы своего конечного автомата, вставлять действия в любой момент, автоматически минимизировать количество состояний и различные другие преимущества. Я упоминал, что сгенерированные автоматы тоже очень быстрые?

Недостатки в том, что их труднее отлаживать (здесь очень помогает автоматическая визуализация) и что вам нужно изучить новый инструмент (который, вероятно, не стоит того, если у вас простая машина, и вы вряд ли будете часто писать машины. )

Я бы использовал переменную, которая отслеживает, в каком состоянии вы находитесь, и переключатель для их обработки:

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 не обязательно зло, и я категорически не согласен с Денисом, да, goto может быть плохой идеей в большинстве случаев, но есть применения. Самый большой страх с goto - это так называемый «спагетти-код», неотслеживаемые пути кода. Если вы можете этого избежать, и если всегда будет ясно, как ведет себя код, и вы не выпрыгнете из функции с помощью goto, то ничего против goto не будет. Просто используйте его с осторожностью, и если у вас возникнет искушение использовать его, действительно оцените ситуацию и найдите лучшее решение. Если вы не можете этого сделать, можно использовать goto.

Избегайте goto, если добавленная сложность (чтобы избежать) более запутывает.

В практических инженерных задачах есть место для goto, которое используется очень экономно. Ученые и не инженеры без нужды заламывают руки над использованием goto. Тем не менее, если вы попадаете в угол реализации, где много goto - единственный выход, переосмыслите решение.

Правильно работающее решение обычно является первоочередной задачей. Правильная и поддерживаемая (за счет минимизации сложности) имеет много преимуществ в течение жизненного цикла. Сначала заставьте его работать, а затем постепенно очищайте его, желательно упрощая и удаляя безобразие.

Я не знаю вашего конкретного кода, но есть ли причина вроде этого:

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

не сработает для вас? Он не использует goto, и ему относительно легко следовать.

Изменить: Все эти State = фрагменты нарушают DRY, поэтому я мог бы вместо этого сделать что-то вроде:

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

что, конечно, намного дольше, чем первая попытка (забавная вещь о DRY). Но он также более надежен - отказ вернуть состояние из одной из функций состояния приведет к предупреждению компилятора, вместо того, чтобы молча игнорировать отсутствующий State = в предыдущем коде.

Я бы порекомендовал вам "Драконью книгу": Компиляторы, принципы-методы-инструменты от Ахо, Сетхи и Уллмана. (Достаточно дорого, но вы наверняка найдете в библиотеке). Там вы найдете все, что вам нужно для синтаксического анализа строк и построения конечных автоматов. Нет места, где я мог бы найти goto. Обычно состояния представляют собой таблицу данных, а переходы - это функции типа accept_space()

Я не вижу большой разницы между goto и switch. Я мог бы предпочесть switch / while, потому что он дает вам место, которое гарантированно будет выполняться после переключения (где вы можете добавить журнал и рассуждать о своей программе). С GOTO вы просто продолжаете прыгать от ярлыка к ярлыку, поэтому, чтобы добавить логирование, вам нужно будет поместить его на каждую ярлык.

Но кроме этого особой разницы быть не должно. В любом случае, если вы не разбили его на функции и не каждое состояние использует / инициализирует все локальные переменные, вы можете получить беспорядок из почти спагетти-кода, не зная, какие состояния изменили какие переменные и что очень затруднит отладку / причину о.

Кстати, можете ли вы проанализировать строку с помощью регулярного выражения? У большинства языков программирования есть библиотеки, позволяющие их использовать. Регулярные выражения часто создают конечный автомат как часть своей реализации. Обычно регулярные выражения работают с произвольно вложенными элементами, а для всего остального существует генератор парсеров (ANTLR / YACC / LEX). Как правило, поддерживать грамматику / регулярное выражение намного проще, чем лежащий в основе конечный автомат. Также вы сказали, что проходили стажировку, и, как правило, они могут дать вам более легкую работу, чем, скажем, старший разработчик, поэтому есть большая вероятность, что регулярное выражение может работать со строкой. Кроме того, в колледже регулярным выражениям не уделяют особого внимания, поэтому попробуйте использовать Google, чтобы прочитать о них.