PetroNotC Sharp,

"Странный Вы" (с)
Где Вы тут увидели ТЗ со временем отклика? Или просто по собственной закомплексованности решили, что "100-400 мс", а не 1-4 мс?
Я видел только задачу: сделать сервер, который должен выполнять команды.

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

Причину, почему я это делаю - описал выше. Так как достало. Кого-то удается приучить писать код оптимально. Но с другими приходится в итоге расставаться, после того как выясняется, что к ним возвращается каждый второй запрос в Jira после code review.

PetroNotC Sharp,

что смешно, практически угадали. Да, один из подобных проектов был на ММК. Но был так же и OTIS, и MOЭК, и Камчатскэнерго и даже Россети с теми же приколами.
Впрочем, сейчас в СУЭК не легче, хоть и нет RS-485.

mayton,

А разве здесь какие-то другие обсуждаются? STM8? Или Padauk? Или если чего-то не знаете, то его не существует? Для AVR, обычно, разработка ведется именно на C/C++. Так что все в рамках темы и топика )

я не собирался перечислять здесь ВСЕ критерии обучения в Бауманке. Я их даже не знаю. Вам не кажется, что Ваше заключение по одному критерию о всех - откровенный признак демагогии )))


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


Кто бы сомневался! )))
Как же еще заставлять потребителя обновлять компьютерный парк почаще? )))

Для приведенного мной примера - нет. Нетехнологично. Если потребуется использовать этот код с совершенно другими кодами устройств, то редактировать коды в статической таблице намного удобней и требует меньше квалификации, чем правка условий в if-ах для этих других кодов устройств.
Табличный подход вкупе с link-time оптимизацией позволяет иметь довольно универсальный конструктор. Легко пополняемый и конфигурируемый под конкретные нужды.

Простите, но тут уже я отошлю Вас читать .

В данном конкретном примере:
"при реализации приема команд на AVR по протоколу NEC (8 бит на устройство и 8 бит на команду), перебирать несколько сот кодов последовательно - недопустимая роскошь. Например, восемь устройств по 32 команды. Для 8-битного процессора разница между между 128 и 9 (на порядок!) обращениям к таблице во флеш памяти - грандиозная."
Использование таблицы и двоичного поиска одновременно сокращает и использование памяти и время выполнения без каких-либо негативных эффектов.

Неужели у Вас настолько ограничено сознание, что фразу "сервер на С++" Вы просто не способны воспринять иначе, как "http сервер"? Ведь запросы к серверу могут вообще через общую память поступать, а не по сети!

Что прикольно, Вы даже не пытаетесь критиковать предложенную мной реализацию по существу. Вы критикуете сам факт предложения оптимизировать алгоритм! Рекомендую научиться читать/слушать чужое мнение. А то Ваше пристрастие к "Золотому молотку" может очень плохо для Вас же и закончится.

Что интересно, с годами таких вещей становится только больше )
Естественно читал. Мне 54 года.

PetroNotC Sharp,

на данный момент ТС протокол не озвучил. Скорее всего, он даже его еще не выбрал. Поэтому я и готов его воспринимать любым: REST, SNMP, ModBus, ProfiBus, HDLC, CAN, LIN, SPI, I2C и т.п. Или даже кольцевым буфером в shared memory с семафором.

Вы же явно демонстрируете приверженность к Золотому молотку

Изначальная постановка:


Итак, 1000 функций, идентифицируемых каким-то признаком (текст или число).
Вопрос: обязательно ли писать тысячу if или case?

Ответ:


То есть, мы в массиве структур разместили 1000 идентификаторов в отсортированном порядке и в паре с указателем на функцию, обрабатывающей запрос с этим идентификатором. Теперь используя двоичный поиск мы можем за 11 обращений к этой таблице вызвать функцию, обрабатывающую полученный запрос.
Профит: меньше кода, меньше потребляемой памяти, быстрее обработка.

А где было сказано, что не должны? )))
Это и есть закомплексованность сознания. Если на найденной вами картинке в качестве протокола сетевого уровня есть только IP, из этого совершенно не следует, что не бывает других протоколов сетевого уровня.
Если на этой же картинке отсутствет протокол SNMP, то из этого совершенно не следует, что он не может быть использован в данном случае.

Про REST бессмысленно спорить, так как это исключительно вопрос терминологии. При одной терминологии протоколом может считаться даже API. При другой - ограничиваемся только OSI. В рамках OSI REST действительно не протокол.