... трёх ...

Привет. Ты оставил 10 однотипных комментариев. Вместо этого лучше оставить один и написать "здесь и везде", "и далее" или что-то такое.

Ёфикацию мы уже обсуждали. Сама я этим заниматься не буду. Максимум - мержить реквесты. Два уже замержено)

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

Для расширяемости решения лучше, чтобы func() получала стек значений (std::vector<>&). С таким подходом можно добавлять функции с количеством значений отличных от 1.

Ни разу не настаиваю.

Предлагаю не усложнять понимание кода и оставить как есть.

Функция save_token() выглядит ненужной. Если всё правильно, то токен с TokenType::Invalid может легально встретиться только первым в списке токенов. В остальных случая появление токена такого типа свидетельствует об ошибке. Сейчас save_token() корректно сработает только на первом токене, в остальных случаях просто скрывает ошибку. (Если я не ошибаюсь конечно.)

Предлагаю TokenType::Invalid переименовать в TokenType::Empty. В дальнейшем игнорировать такой токен, если он первый. Во всех остальных случаях сигнализировать об ошибке.

Глядя на функции start_accumulating_number(), accumulate_number(), accumulate_operator() и accumulate_parenthesis() напрашивается класс Tokenizer. ИМХО, такой подход правильнее.

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

Переписала все на токенайзер + свич-кейс.

AFAIR, в C++23 появилась возможность обозначать неиспользуемые переменные префиксом _. Если _ не работает, то убрать либо закомментировать tokens.

Да. Переделала.

Не очень хорошо, что можно создать неинициализированный объект типа Transition. Предлагаю сделать конструктор Transition(State state, TransitionAction act), где:

using TransitionAction = std::function<void(char, Token &, std::vector<Token> &)>;

Тогда конструктор по умолчанию будет недоступен.

Эта штука больше не нужна. Удалила.

Row — неудачное и неговорящее навание. Может лучше TransitionMap?

Этой штуки больше нет.

А разве не так нужно делать:

std::isdigit(static_cast<unsigned char>(c))

?

Не, все в порядке:

int isdigit( int ch );

https://en.cppreference.com/w/cpp/string/byte/isdigit.html

Мне не очень нравится, что определение типа символа (токена по факту) и соответствующая ошибка происходит вне машины состояний. Это должна быть её часть. Допустим у нас было бы более сложное задание, допускались бы шестнадцатиричные значения и функции. В этом случае что означал бы символ A? Это шестнадцатиричные число или начало имени функции (например ABS)? Обрати внимание, что понять тип токена в случае ABS можно только на символе S.

Не хватает шага определения типа токена. Это первый шаг при начале разбора на токены и он же нужен после завершения текущего токена:

def_type => number => def_type => operator => def_type =>parenthesis => def_type => ...

При этом текущий токен может завершаться при встрече неподходящего символа двумя способами:

• переходом на шаг определения типа токена, например: 9.71v (v - невалидный символ, но токен число ничего об этом не знает, а def_type знает);
• ошибкой, например: 9.71. (. - валидный символ, но может быть только раз).

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

P.S. И где классы черт подери! :) Пока какой-то Си-стиль получается ;)

Переделано на класс Tokenizer.