Здравствуйте.

Написан конечный автомат на конструкции switch - case. Для перехода к последующему действию просто инкрементируется указатель:

Действий порядка 100 и возникла проблема с добавлением новых case-обработчиков в середину конструкции, т.к. приходится увеличивать все последующие номера case.

Хочется перенести эту задачу на плечи препроцессора и оформить конструкцию таким образом, чтобы название макроопределения case было у всех одинаковым и, в тоже время, каждое последующее значение было на 1 больше предыдущего:

Подскажите, пожалуйста, возможно ли это как-то реализовать?
Спасибо.

Так получится?

"В лоб" задача решается применением enum.
В середину такого конечного автомата легко добавляется любое количество новых состояний. Конечно, придумать около 100 названий для сотояний и не сорваться на использование цифр в этих названиях - задача непростая.

Значения после case должны быть разными. Иначе компилятор просто не станет компилить.
Я в подобных случаях использую enum. При добавлении хоть в середину хоть в конец нет проблем с перенумерацией.
enum { //фазы автомата состояний
INCNAME_SOST0, INCNAME_SOST1, INCNAME_SOST2, ...};


Не компилил, но почти уверен, что на такую конструкцию компилятор скажет: "Undefined behavior".

Компилируется даже без предупреждений.
Единственное, в {} не должно быть i++.
Лучше new_i++, а в самом конце i = new_i.
Иначе автомат выстрелит очередью.

Создаете в Excel одну строку с одним макроопределением.
Потом протягиваете ее до 100 строк и получаете идеальный инкремент.
Если нужно вставить что-то в середину, то в вставляете в Excel-е и снова протягиваете, получите новый инкремент.
Потом Copy-Paste из Excel-а
Нажмите для просмотра прикрепленного файла

А числа на макросы заменяются автоматически с использованием регулярного выражения.

Подход с enum, несомненно, правилен.
Однако, при добавлении состояний, потребуется редактировать в двух местах.

Только надо предусмотреть ловушку какую на случай если __COUNTER__ был ранее использован.
https://gcc.gnu.org/onlinedocs/cpp/Common-P...edefined-Macros

Есть такая реализация, сделана на swich/case и __LINE__
http://dunkels.com/adam/pt/index.html

Что говорит о том, что решение поставленной задачи только с помощью конечного автомата зашло в тупик .
Думайте о комбинации методов. Более-менее типичный выход из такой ситуации это использование наряду с состоянием конечного автомата дополнительных битовых флагов.

Да нормально, есть прикладные протоколы с очень большими словарями.

Только вот enum для этого негодное средство,
поскольку при отладке невозможно узнать значение макроса и приходится все равно либо в комментариях либо прямым присваиванием вписывать числа.

Не путайте протоколы с их РЕАЛИЗАЦИЕЙ через анус. Сотня состояний конечного автомата это уже анус.

Отладка сколь-нибудь серьезных ПРОТОКОЛОВ отладчиком есть абсолютно непригодное средство, ибо все проблемы взаимодействия оборудования раснообразных производителей начнутся не тогда, когда все лежит на столе.
Так что логирование состояния конечного автомата обязательно, ну а при логировании разворачивание названий состояний в текст так же обязательно. Все это решается через общую функцию изменения состояния автомата. Например:

Прямо сейчас у меня в работе протокол с 41-им case в парсере.

Линейная структура кода позволяет легко его форматировать и рефакторить.
Регулярные выражения замены легче писать под такую структуру кода.
Работает она быстрее.
Короче одни плюсы.

Протоколы только отладчиком через SWD и можно детально отладить.
Логи для протоколов - это во первых медленно, во вторых менее информативно, в третьих сами вносят нежелательный эффект в виде роста стека задач и ухудшения реалтайма.

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

Трудно припомнить название?

gdb + eclipse.

Понятно. Я всегда говорил, что языки это эхо средств редактирования и отладки.
А вот в IAR и Keil применение enum будет неудобным.
Я, кстати, enum уже давно не применяю. Одни проблемы от них.

Можно сделать завуалированный конечный автомат, без огромных перечислений enum. На стеке.
Будет что-то типа задачи со своим стеком, очередное состояние - это собственно адрес. Вход в автомат - это переключение на его стек, выход (там где был break) - обратное переключение на исходный стек.
Очень удобно отлаживать. Но конечно требуется некоторая дополнительная память (стек).
Я так иногда делаю когда автомат получается ну очень сложным, да ещё с вложенными ветками.

Где же тут удобство?
Вижу только проблемы для статического анализатора.
Хранение состояний в стеке приведет к тому что в окне отладчика для переменных они будут большую часть времени не видны.

Зря не смотрели в сторону
http://dunkels.com/adam/pt/index.html
и enum не нужны

А зачем их видеть? Очередное состояние автомата - это собственно начало очередного участка кода.
Если Вам (для отладки) нужно видеть состояние автомата в моменты выполнения кода за пределами кода автомата, то в функции-переключателе контекста можете сохранить адрес в любую переменную.
Удобство в том хотя-бы, что код линеен, а не вермишель из case ...

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

В Вашим? Да хоть 4141 case. Это ВАША РЕАЛИЗАЦИЯ некоего протокола, которая делатся через ... Попытайтесь найти спецификацию протокола в котором используется такое количество СОСТОЯНИЙ хоть на каком-то уровне.

... поехав на край земли с "отладчиком" и сидя на столбе выяснять что это, вдруг, от того, что на противоположном конце земли кто-то, например, заапгрейдил Cisco не может связаться с Магаданом. Да, да внутрисхемный отладчик это очень "полезная" штука в таких ситуациях .

Примерно так (код вне к.автомата - там где у ТС switch; код автомата - набор case-участков состояний к.автомата):
1. Выполняется код вне к.автомата. На месте switch() ставим переключение контекста на отдельный стек (в стеке сохранён контекст задачи автомата со всеми сохранёнными регистрами и адресом возврата).
SwitchContext(адрес_структуры_контекста_со_стеком).
Внутри функции SwitchContext() сохраняем текущий контекст на текущем стеке, переключаемся на стек к.автомата, восстанавливаем контекст из него и осуществляем возврат в код к.автомата.
В коде к.автомата, выполнив очередную ветку case, опять вызываем SwitchContext(), которая сохранит контекст к.автомата на его стеке, переключится на исходный стек задачи, вызвавшей к.автомат и восстановит контекст из него и осуществит возврат.
Код к. автомата будет выглядеть:

Как видите - код к.автомата получается линейным и легко читаемым даже при наличии ветвлений. А в традиционной реализации к.автомата при неск. ветвлениях по состояниям автомата уже получится малочитаемый вермишельный код.
А представьте, если вдруг окажется необходимым из некоторых состояний к.автомата проходить цепочку других его состояний с возвратом потом в исходную точку:
сост0
сост1
сост10
сост11
сост12
сост2
...
сост5
сост6
сост10
сост11
сост12
сост7
...
В традиционной реализации придётся ещё куда-то сохранять/восстаналивать состояния автомата. И вообще получится лес.
А с переключением контекста, будет просто вызов функции.

Уменьшение количества состояний чаще всего достигаеся увеличенем количества автоматов. Все сколь-нибудь вменяемые протоколы разбиты на уровни и обслуживаются на каждом уровне своими автоматоми. Если безмозгло свалить все уровни в одну кучу, то получим именно катострофический рост состояний при котором "41 case" от AlexandrY и "100" от Alt.F4 это даже еще не цветочки

Это да, можно и так.
Но бывают даже относительно короткие автоматы в 10-20 состояний, но со сложной логикой ветвления, условными переходами между состояниями или необходимостью выполнения повторяющихся цепочек состояний в разных местах автомата.
Я не говорю конкретно про разбор кадров протокола, вопрос был общего плана об к.автоматах.

Protothread это не про протоколы.
Поскольку там используется много неявных выходов из функции, то в сложных десериализаторах придется много кода потратить на сохранение контекста.
Поскольку контекст десереализации не ограничивается только номером состояния как в Protothread.
По мне лучше уж goto чем такие хитрые переходы.


В вашем псевдокоде я вижу только множественные SwitchContext() без аргументов. Это выглядит как полная бессмыслица.
Стек - это в вашем понятии стековая структура данных или стек процессора?
Стековые структуры обычно применяют для раскрытия рекурсии в парсерах. У меня так работают парсеры JSON, LUA и еще несколько.

Но в протоколах нет рекурсий. Там есть именно разбор вариантных хидеров. Ничего лучше case для этого не придумано.

Protothread это скрытый switch без enum и прочей ерунды.
Контекст всегда можно сделать структурой и устанавливать указатель при входе.
Ограничение только на динамические переменные.
Смысл простой - использование __LINE__ для автогенерации switch/case
Всё остальное - как угодно.

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

TC же показал способ с вычисляемыми ключами. Ему Protothread никак не подойдет.

Несомненно! По этой причине я тоже с самого начала писал, что просто не надо все всегда ТОЛЬКО на состояния автомата валить. В каждом конкретом случае надо смотреть, как разгружать собственно автомат от излишества состояний, ибо конечный автомат не есть панацея . Совсем недавно в казалось-бы простой задаче начал в лоб писать автомат - началось погружение в пучину состояний. Разбил на два автомата - тоже не сильно понравилось, ибо такой подход нормально работает, когда протокол на уровни бьется. В результате был сделан один автомат на 13 состояний и три бита дополнительных глобальных статусов.

Это просто Ваши познания в протоколах невелики . В тех же телекомуникационных протоколах в полученном фрейме может находится, или не находится, самая разнообразная информация. Причем, как относящаяся к одному объекту, так и к разным. А сам фрейм собираться из множества небольших кусочков. Вот и начинается рекурсивный разбор полей.

Вы уж определитесь о чем хотите рассказать.
Сначала у вас многоуровневые концепции, теперь опять рекурсивные.

Фреймы из кусочков это связные списки, а не стековые структуры.
Я не видел рекурсию на в TCP/IP, ни в Zigbee, ни в BLE, ни в USB... Ну ни где.
А вы где усмотрели?

О том, что и написал в первом посте. Если количество состояний автомата начинает измеряться десятками и тем более сотнями, то конечный автомат пишется НЕПРАВИЛЬНО. Как с этим бороться - рецепты разные. В том числе и рекурсия в явном или неявном виде.

Вот я и говорю, что познания Ваши невелеки .
Есть целые пласты протоколов находящиеся далеко за пределами сознания бытовых компьютерщиков. Они, напрмер, живут здесь: https://en.wikipedia.org/wiki/ITU-T отличительная их особенность, что создавались и оттачивались они годами и десятилениями и служат не для того, что бы какая нибудь фирма могла быстро родить урода по собственному невеликому разумению и засрать рынок заставля конкурентов ковыряться в дерьме добиваясь совместмости и работоспособности. А совсем с противоположной целью. При этом типовой ITU-ный стиль описания протоколов это конечные автоматы. Так уж получилось, что большую часть своей жизни я занимался именно телекомуникационными протоколами. Отчего и образовался более, чем скептический взгляд на то, что рожают и изобилии околокомпьютерщики и что является, как например, TCP/IP в лучшем случае огрызком давно существующих стеков протоколов.

Не могли бы Вы, zltigo, уточнить в каком именно протоколе ITU-T рекурсивный разбор полей?

Он наверно имеет в виду DHCP где минимум 71 case в реализации.
Протоколы ITU-T из-за их всеядности и резиновости просто кошмарное количество switch-case требуют.

Как ТРЕБОВАНИЕ реализовывать что либо рекурсивно - естественно, в описании протоколов этого нет. Описание протроколов никак не описывает способов их реализации, хотя на верхнем уровне протокол описывается как конечный автомат и соответственно подталкивает на этот путь.
В конкретной реализации протокола все уже на откуп того, кто реализовывет. Я использовал рекурсивные вызовы автомата уже на уровне MTP3.

С каких пор студенческий самодуй DHСP стал иметь отношение к ITU? Разномастные огрызки разных RFC это вообще не стандарт.

ITU-T протоколы не требуют "кошмарных" количеств "case". По причине того, что они изначально разделены и хорошо суктурированы по уровням. Если же практическую реализацию делать бездумно смешивая в одну кучу что попало, то тогда, конечно, количество состояний для обеспечия функционирования можно раздувать хоть до "71" хоть до тысяч.
DHCP с 71 case, это как раз пример безмозглого подхода к делу в стиле давай-давай, что тут думать трясти надо. Это обычно для "компьютерщиков", которые недоучившись и недопоняв сначала сотворив огрызок TCP/IP из того, что смогли понять в X.25 стеке, начали городить бездумно городить "протоколы" и дальше.
В результате начальное "упрощение", выкидывание, объедиение и усечение уровней ведет при попытке реализовать что либо сложнее, чем "два байта переслать" к каше из уровней, множества заплаток и появлениям "DHCP где минимум 71 case". Я все понимаю, почему так все растет - бурно в 70x началась компьютеоизация и микроконтролизация. Все сделать сразу по уму и аккуратно было сложно, или воообще почти невозможно из-за отсутсвия те-же аппаратных ресурсов. Мозговых ресурсов тоже не хватало - хлынул поток студентов нахватавшихся только вершков. Все понятно. И то, что выросло, то выросло http://inet777.ru/esli-byi-stroiteli-stroi...vilizaciyu/8476

Задавал я аналогичный вопрос
тут
но реализация через boost меня ужаснула.
Вместо С-препроцессора проще сделать свой для pre-build.
Так и сделал. Так и доволен сделаным.

А я таки не понял, чем enum плох?
Мало того, что все по порядку, так можно добавить последний элемент eNumOfItems и получить автоматически количество элементов, которое можно вставить в определения массивов или в циклы, etc.

Правильное тактическое применение enum это когда назначаешь переменной символьное имя и проверяешь всегда у нее только символьное имя.
А если надо enum сравнивать с int то это уже неправильное применение enum.
О чем отладчики и намекают не показывая числовое значение переменной с типом enum.

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

Нынче длинные switch-case редко встретишь потому что протоколы разрослись настолько, что им этот механизм стал мал. Строят целы базы данных в виде таблиц с сотнями и тысячами записей.
Для такого switch-case просто физически писать уже невмоготу, потому при разборе протоколов переходят на движки с поиском по базе данных. Взгляните на ATT в BLE
Это ухудшает конечно производительность, но и процессоры стали быстрее.

Это ЗНАНИЕ разработчика, который ЗНАЕТ, что если разрабатывать и писать реализации через анус, то case разрастаются немеряно. Что свидетельвует о НЕПРАВИЛЬНОМ подходе к реализации. О чем сразу в первом посте и написал. О том, что "современные" приложения рожают через анус, потому, что и ума и времени нехватает, тоже писал.

Теперь, если вернуться к TC и case, то очень, очень полагаю, что ничего сколь-нибудь выдающищегося и затмевающего своей сложностью "ATT в BLE" и иже с ним он не пишет, а просто и банально из-за необдуманости реализации тонет в плодящихся состояних конечного автомата .

Вообще то сам по себе инкремент состояния - это потенциальная угроза ошибки. Сейчас ручками вписываю конкретное текстовое состояние перехода (из enum, или enum+X-macro).

Я бы так делать не стал, но все же...

Если надо что-то "проинкриментировать" - надо сгенерировать некую таблицу (массив const структур во флеш), или несколько таблиц с требуемой инф-ей.
Опятьже - сделать свой препроцессор. ОНО будет читабельнее, логичнее без идиотизма когда средство важнее цели.
Если конечно цель - не сделать "глухой" проект, в котором только писатель и разбирается.




Вот я по Вашей наводке так и делаю. Гранд мерси
enum - генерация последовательных индексов массива,
и ониже - для инициализации массива констант-структур.
(реализация сколько-угодно-уровневого меню).

k155la3

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

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

А кто придумывает номера для "состояний"?
При добавлении новой записи нужно править поле "перейти в новое состояние" предыдущей записи?
Или можно ставить только поля "событие" и "выполнить действие" а выполняться все будет линейно пока не дойдет до конца таблицы?

Еще один enum

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

Как быть с ветвлением, т.е. если новое состояние определяется исходом действия?

Чтобы не заморачиваться с ручной адресацией массива-таблицы, можно примерно так.
(но таблиц нужно 2 - одна состояний, вторая - переходов, в которую включены указатели на функции-обработчики)
IMHO

По исходу действия генерируем событие, в таблице описываем переход по этому событию в нужное состояние.

У меня таблица выглядит так

Терминология MONOBLOCK и _ana_ не из оперы modbus. Всегда поражаюсь людям изобретающим велосипеды...

Опечатка?
Я хронический лентяй, программа работает на изделии с 2002 года. Исправлять лениво :-)



Моноблок - это блоки нашей разработки на кастомном протоколе. А сие поделие является шлюзом в Modbus.

Вот, кстати, ссылка на автомат конечных состояний, описанный таблицей, управляемый событиями.
http://chipenable.ru/index.php/programming...nizatsiya-progr