Jump to content

    

Инкрементирующийся define

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

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

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

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

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

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

 

 

 

Share this post


Link to post
Share on other sites

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

Share this post


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

 

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

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

Share this post


Link to post
Share on other sites
Не могли бы Вы, 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

Share this post


Link to post
Share on other sites

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

тут

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

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

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

 

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
А я таки не понял, чем enum плох?

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

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

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

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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites
Это заблуждение разработчика видимо давно не имевшего практику разработки современных приложений.

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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;

...
}

 

Share this post


Link to post
Share on other sites

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

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

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

 

 

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

 

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

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

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

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

Edited by k155la3

Share this post


Link to post
Share on other sites

k155la3

 

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

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

Share this post


Link to post
Share on other sites
А кто придумывает номера для "состояний"?

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

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

 

Еще один enum

 

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this