[zltigo 0]

Вы уж определитесь о чем хотите рассказать.

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

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

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

Вот я и говорю, что познания Ваши невелеки :(.

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

 

 

 

[Kabdim 0]

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

[AlexandrY 2]

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

 

Он наверно имеет в виду DHCP где минимум 71 case в реализации.

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

[zltigo 0]

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

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

В конкретной реализации протокола все уже на откуп того, кто реализовывет. Я использовал рекурсивные вызовы автомата уже на уровне MTP3.

Он наверно имеет в виду DHCP где минимум 71 case в реализации.

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

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

ITU-T протоколы не требуют "кошмарных" количеств "case". По причине того, что они изначально разделены и хорошо суктурированы по уровням. Если же практическую реализацию делать бездумно смешивая в одну кучу что попало, то тогда, конечно, количество состояний для обеспечия функционирования можно раздувать хоть до "71" хоть до тысяч.

DHCP с 71 case, это как раз пример безмозглого подхода к делу :( в стиле давай-давай, что тут думать трясти надо. Это обычно для "компьютерщиков", которые недоучившись и недопоняв сначала сотворив огрызок TCP/IP из того, что смогли понять в X.25 стеке, начали городить бездумно городить "протоколы" и дальше.

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

[k155la3 26]

Задавал я аналогичный вопрос

тут

но реализация через boost меня ужаснула.

Вместо С-препроцессора проще сделать свой для pre-build.

Так и сделал. Так и доволен сделаным.

 

[MrYuran 16]

А я таки не понял, чем enum плох?

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

[AlexandrY 2]

А я таки не понял, чем enum плох?

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

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

А если надо enum сравнивать с int то это уже неправильное применение enum.

О чем отладчики и намекают не показывая числовое значение переменной с типом enum.

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

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

 

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

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

Это ухудшает конечно производительность, но и процессоры стали быстрее.

[zltigo 0]

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

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

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

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

[DogPawlowa 0]

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

[yanvasilij 0]

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

 

switch (i)
{
#define INC_DEF 0
#define TMP_DEF INC_DEF+1
case INC_DEF:
	...
	break;

#undef INC_DEF
#define INC_DEF TMP_DEF
#undef TMP_DEF
#define TMP_DEF INC_DEF+1

case INC_DEF:
	...
	break;

#undef INC_DEF
#define INC_DEF TMP_DEF
#undef TMP_DEF
#define TMP_DEF INC_DEF+1
case INC_DEF:
	...
	break;

#undef INC_DEF
#define INC_DEF TMP_DEF
#undef TMP_DEF
#define TMP_DEF INC_DEF+1

case INC_DEF:
	...
	break;

...
}

 

[k155la3 26]

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

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

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

 

 

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

 

Вот я по Вашей наводке так и делаю. Гранд мерси :)

enum - генерация последовательных индексов массива,

и ониже - для инициализации массива констант-структур.

(реализация сколько-угодно-уровневого меню).

Изменено 13 июля, 2016 пользователем k155la3

[yanvasilij 0]

k155la3

 

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

[Andrew_Q 0]

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

[adnega 10]

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

А кто придумывает номера для "состояний"?

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

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

[Andrew_Q 0]

А кто придумывает номера для "состояний"?

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

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

 

Еще один enum

 

Если при правке выясняется, что нужно перейти в другое состояние, то да, нужно исправлять.

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