как писать на С в 2016 году Опции

[Jenya7]

прочитал интересную статью. решил поделиться.
https://habrahabr.ru/company/inoventica/blog/275685/

[sigmaN]

Указатель на стуктуру более, чем достойный уровень абстракции и хорош, как минимум тем, что должен быть получен в процессе инициализации системы и будет иметь свое имя.
Номер-же порта эта не абстракция а муть бесфоменная - вызов какой-либо функции с номером порта '9' не говорит ни очем.

писать просто 9 это тоже не правильно даже с точки зрения ненавистного AlexandrY Фаулера. В программе не должно быть магических чисел, поэтому конствнта UART_9, определенная на все случаи жизни в том же хидере драйвера порта вполне бы подошла.
Конечно же и Фаулер и Совершенный Код, Макконнелла, тут тоже не в почете ибо они дескаать сделал карьеру на финансовых системах, а тут всё-же по большей части сидят представители "старой школы", привыкшие считать байты и такты порой даже тогда, когда этого делать не нужно. В то время как я в вышеупомянутых трудах не увидел вредных советов, способных ухудшить код и дизайн эмбеддед системы. Как раз с точностью до наоборот!

И абсолютно ясно, что в 2016году пора мыслить в категориях ООП и писать на С++. О чем кстати упоминалось в этой ветке уже.
И что C++ can be as efficient as C это уже не мечты и не легенды, тем кто в теме, тоже ясно.

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

А я говорю, что добираться до элемента структуры не надо вовсе, а работать с портом надо через интерфейс драйвера UART, который таки да, по номеру порта разберется с чем надо иметь дело и к какому регистру обратиться по запросу GetTXCompleteFlag(UART_9) и выдаст нужный результат. И за UART_9 может стоять хоть целый эзернет и удаленный на 1000км UART, хоть USB-UART переходник - не важно.
И таки никто не говорит, что сопоставление номера к регистру или вычисление адреса должно непременно происходить на этапе выполнения программы )

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

Я вот исключительно из этих соображений оправдывал абстракцию API драйвера до номера порта. И таки да, я согласен, что если придется сопоставлять номер структуре в рантайме то это вносит некоторый оверхед и использовать регистры напрямую прям в коде это на много меньше лишних телодвижений. И что это меняет? Это отменяет необходимость профилирования и выявления узких мест чтобы вставить костыли ТОЛЬКО туда? НЕТ.

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

Когда-то я уже приводил тут одну замечательную статью о том, как можно эффективно реализовывать правильные с точки зрения и Фаулера и Макконнела вещи на 8ми битниках и без рантайм оверхеда. Очень советую ознакомиться. http://easyelectronics.ru/rabota-s-portami...erov-na-si.html
Пользуюсь лично и пока не видел лучшего решения поставленной задачи.
Считаю, что это и есть пример того, как нужно программировать в 2016г. Алсо с введением стандартов С++11 и 14 реализация этой библиотеки будет на много проще и компактнее.