Comments 24
get_var я бы вместо функции записал через шаблонный using .
Избавиться от айдишников можно при помощи boost fusion/hana
Лямбда кучу не использует- она и есть функтор и её размер всегда известен на этапе компиляции.
Не очень понимаю зачем вообще было делать очередь если все actions аллоцируются внутри SM — это побуждает использовать статическую переменную для машины, не круто помоему.
Спасибо за комментарий и наводки, посмотрю!
Когда думал об очереди, держал в голове примерно такой сценарий.
Мы находимся в стейте, где, скажем, отрисовываем что-то на экране. Из этого стэйта мы можем перейти в два других по двум разным эвентам. В это время из прерываний нам прилетают 4 эвента, два «наших» с разными приоритетами, и два — для следующих стэйтов. Как тут обойтись (и можно ли) без очереди я пока не знаю. Можно, конечно, возразить что архитектурно не нужно допускать описанных ситуаций, но в том и смысл всяческих диспетчеров и атоматов, чтобы обеспечить гибкость в разработке.
Когда думал об очереди, держал в голове примерно такой сценарий.
Мы находимся в стейте, где, скажем, отрисовываем что-то на экране. Из этого стэйта мы можем перейти в два других по двум разным эвентам. В это время из прерываний нам прилетают 4 эвента, два «наших» с разными приоритетами, и два — для следующих стэйтов. Как тут обойтись (и можно ли) без очереди я пока не знаю. Можно, конечно, возразить что архитектурно не нужно допускать описанных ситуаций, но в том и смысл всяческих диспетчеров и атоматов, чтобы обеспечить гибкость в разработке.
Тогда это нарушение SRP. Очередь входящих событий — это одно, обработка событий и переход по состояниям — другое. Если писать переиспользуемый код, надо это разносить в разные классы и думать, чтобы это хорошо работало вместе.
Дело говорите! Но статья преимущественно о том, как взять себя за яйца постараться и повторить в концепте/эксперименте задумку крутого чувака из Яндекса. Безусловно до кода, готового к продакшену очень далеко, но я потихоньку допиливаю…
Нет, это не нарушение SRP, у него StateMachine имеет прямой доступ к очереди и на запись и на чтение.
Можно прочитать каноническое математическое определение FSM и убедиться, что там нет никаких входных очередей.
И что из этого? Математическую конструкцию в компьютере не запустишь.
Вот у автора есть очередь, это теперь не FSM?
Вот у автора есть очередь, это теперь не FSM?
И что из этого? Математическую конструкцию в компьютере не запустишь.Математическая конструкция описывает интерфейс, а тут интерфейс больше, чем необходимо.
Вот у автора есть очередь, это теперь не FSM?
Ну давайте в std::vector добавим sort, сериализацию из/в XML и автоматическое отслеживание top 3 наиболее часто встречающихся элементов. А что такого, удобно же.
Канонически очередь нужна даже для однопоточных приложений
Например если у вас action где выполняется работа и посылается сигнал навешен на state с безусловным переходом. Тот же SCXML стандартизует это поведение.
Но у Вас в коде ситуация что action аллоцируется внутри StateMachine, а значит по хорошему он доступа к StateMachine не имеет.
Как бы я поступил — таблица переходов как контейнер объектов-состояний и объектов-действий аллоцируется вне StateMachine (соответственно можно вызвать конструкторы и назначить внутренние состояния) и заменить operator()() на operator()(StateMachineHandle&) где ручка это штука которая даёт доступ к send_event и set_guard. (и возможно вычисляемые guards это не плохая идея)
Например если у вас action где выполняется работа и посылается сигнал навешен на state с безусловным переходом. Тот же SCXML стандартизует это поведение.
Но у Вас в коде ситуация что action аллоцируется внутри StateMachine, а значит по хорошему он доступа к StateMachine не имеет.
Как бы я поступил — таблица переходов как контейнер объектов-состояний и объектов-действий аллоцируется вне StateMachine (соответственно можно вызвать конструкторы и назначить внутренние состояния) и заменить operator()() на operator()(StateMachineHandle&) где ручка это штука которая даёт доступ к send_event и set_guard. (и возможно вычисляемые guards это не плохая идея)
Избавиться от айдишников можно при помощи boost fusion/hana
Возможно не всем потенциальным пользователям библиотеки понравится зависимость от boost
Не устаю удивляться изобретательности программистов, которые, вместо того, чтобы сделать нормальный развитой препроцессор для С(С++), изворачиваются с шаблонами, заставляя их делать то, для чего они не очень приспособлены. К сожалению, это разные программисты.
Спасибо, что потратили свое время на мою статью! Когда любишь плюсы, эти извороты в радость, да и вечно ленивый мозг попинать не вредно будет.
Конечно разные, автор статьи — программист на С++, а те кто так не умеют — программисты на си с классами. Шаблоны были созданы именно для этого, все развитие С++11 и выше крутится вокруг них.
Так же сейчас работаю в сфере embedded, и все чаще прихожу к мыслям, что надо переходить на rust или C++. Спасибо за статью.
Одной из целью запуска своего мелкого «пет» проекта (на stm32f769) было освоение плюсов в данном контексте.
Есть хорошая книжка «Real-Time C++ by Christopher Kormanyos». Много интересного именно в контексте применения современного С++ на мк.
Одной из целью запуска своего мелкого «пет» проекта (на stm32f769) было освоение плюсов в данном контексте.
Есть хорошая книжка «Real-Time C++ by Christopher Kormanyos». Много интересного именно в контексте применения современного С++ на мк.
Конечно же прочитана в свое время от корки до корки. Рекомендую искать издание от 2018 г., там примеры с точки зрения плюсов посвежее.
А не попадалась ли вам вот эта книга: www.state-machine.com/psicc («Practical Statecharts in C/C++») — старая, но довольно любопытная. Автор разработал свою библиотеку для реализации иерархических FSM (предыдущее издание называлось «Hierarchical State Machines in C/C++»), программируя для embedded-устройств (GPS, как мне помнится).
Ааа, QL, позиционируют себя как альтернатива RTOS, если не ошибаюсь. Сильно не вникал, увы.
У него свой канал есть, а книга на либгене есть
www.youtube.com/channel/UCMGXFEew8I6gzjg3tWen4Gw
www.youtube.com/c/StateMachineCOM/videos
А ТС-у имеет смысл посмотреть на библиотеку
github.com/taskflow/taskflow
www.youtube.com/channel/UCMGXFEew8I6gzjg3tWen4Gw
www.youtube.com/c/StateMachineCOM/videos
А ТС-у имеет смысл посмотреть на библиотеку
github.com/taskflow/taskflow
Имел опыт использования boost::msm под QNX:
1. Не нашел каким образом с помощью API узнать текущий стейт.
2. Из-за большой вложенности шаблонов в определенный момент начался крешится QNX линкер. Пришлось выкручиваться путем разбиения основной машины на под машины.
3. Так же очень медленная компиляция и огромные дампы ошибок компилятора.
1. Не нашел каким образом с помощью API узнать текущий стейт.
2. Из-за большой вложенности шаблонов в определенный момент начался крешится QNX линкер. Пришлось выкручиваться путем разбиения основной машины на под машины.
3. Так же очень медленная компиляция и огромные дампы ошибок компилятора.
Кстати, большей частью из-за указанных вами недостатков, упомянутый мной С. Федоров и взялся написать свою библиотеку FSM. Шаблоны это, конечно, нитроглицерин — малейшая неострожность, и компилятор бомбанет, мало не покажется) Но до чего захватывающая штука! В азарте сложно держать баланс между реальными требованиями задачи и использованием шаблонов ради любви к шаблонам.
Довольно много игрался с конечными автоматами и симпатизирую этому подходу. Но по моему личному опыту очень привлекательная идея FSM при реализации только в коде плохо масштабируется на большие/сложные автоматы. Нужны инструменты с визуализацией, моделированием и верификацией, но они обычно порождают не самую эффективную реализацию, нормально использовать которую можно только при избытке вычислительного ресурса (типа CCXML для ненагруженной телефонии).
Поэтому если с ресурсами не очень, как на МК, то с годами стал предпочитать более прямолинейный подход с упором на дизайн и продумывание задачи: та или иная форма «акторной архитектуры» с максимальной декомпозицей событий и провдедением четко ограниченных и нагруженных контекстом с данными событий через очередь в тот или иной «актор»-обработчик. Рад был бы, если шаблоны тут сильно помогали, но у меня не сложилось такого впечатления. Нет, если взять хороший фреймворк типа SObjectizer или QP, то получается очень даже поддерживаемо.
А увлечение шаблонизацией где надо и не надо — это детская болезнь, которая проходит с появлением реальной ответственности за сроки и поддержку своих проектов. Вырабатывается чувство, когда просто интересно и когда полезно.
Поэтому если с ресурсами не очень, как на МК, то с годами стал предпочитать более прямолинейный подход с упором на дизайн и продумывание задачи: та или иная форма «акторной архитектуры» с максимальной декомпозицей событий и провдедением четко ограниченных и нагруженных контекстом с данными событий через очередь в тот или иной «актор»-обработчик. Рад был бы, если шаблоны тут сильно помогали, но у меня не сложилось такого впечатления. Нет, если взять хороший фреймворк типа SObjectizer или QP, то получается очень даже поддерживаемо.
А увлечение шаблонизацией где надо и не надо — это детская болезнь, которая проходит с появлением реальной ответственности за сроки и поддержку своих проектов. Вырабатывается чувство, когда просто интересно и когда полезно.
Sign up to leave a comment.
Достучаться до небес, или FSM на шаблонах