Инкрементирующийся define, c помощью препроцессор Си Опции

[Alt.F4]

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

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

Код

switch(i)
{
case 0: ... i++;
case 1: ... i++;
...
case N: ... i++;
}

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

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

Код

switch(i)
{
case INCNAME: ... i++;
case INCNAME: ... i++;
...
case INCNAME: ... i++;
}

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

[zltigo]

Действий порядка 100...

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

[jcxz]

Что говорит о том, что решение поставленной задачи только с помощью конечного автомата зашло в тупик .

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

[zltigo]

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

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

[jcxz]

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

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

[zltigo]

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

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

Но в протоколах нет рекурсий...

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

[AlexandrY]

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

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

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

[zltigo]

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

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

Я не видел рекурсию на в TCP/IP, ни в Zigbee, ни в BLE, ни в USB... Ну ни где.

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