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

Вот я и говорю, что познания Ваши невелеки .
Есть целые пласты протоколов находящиеся далеко за пределами сознания бытовых компьютерщиков. Они, напрмер, живут здесь: 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 - Jul 13 2016, 06:55

k155la3

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

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

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

Еще один enum

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