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

[Jenya7]

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

[EvilWrecker]

А где тут интересные моменты? Всегда считал данный ресурс местом сбора закомплексованных веб-дезигнеров разного пошиба,почему-то мнящих себя элитным сообществом(и разумеется таковым не являющимся), но весьма желающим быть генератором трендов в области языков/методологий программирования - почти что кузницей истин. Получается это у них подчеркнуто мерзко- в этом смысле по убогости с такими постами могут конкурировать разве что DIY проекты и печатные платы с гиктаймса. Особенно веселят персонажи предрекающие скорую гибель языкам группы C и тыкающие везде своими поделиями имеющими в названии слово java- ну а что с низ взять, с элитных веб-дезигнеров?

[Эдди]

Быдлохабра сейчас еще хуже стала, потому что интересные вещи, которые там когда-то можно было найти (как рисинку в ведре с дерьмом), перекочевали на какой-то "гиктаймс". А БХ теперь — тупо сборище поганой безмозглой вантузячьей школоты.
По делу: С — он и в Африке С. И писать на нем точно так же, как 30 лет назад. Ничего не изменилось.

[AlexandrY]

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

Это компьютерный С-и , а встраиваемый С-и он совсем другой.
Для него больше половины что там написано либо не действительно, либо все делается наоборот.

[Jenya7]

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

Код

Мы НЕ делаем так:
void test(uint8_t input) {
    uint32_t b;

    if (input > 3) {
        return;
    }

    b = input;
}

Вместо этого пишем следующим образом:
void test(uint8_t input) {
    if (input > 3) {
        return;
    }

    uint32_t b = input;
}

или

Код

Классическая ошибка:
  struct thing {
        uint64_t index;
        uint32_t counter;
    };

    struct thing localThing;

    void initThing(void) {
        memset(&localThing, 0, sizeof(localThing));
    }

Корректно:
struct thing {
        uint64_t index;
        uint32_t counter;
    };

    struct thing localThing = {0};

мелочь а приятно. буду править сорцы.

[Эдди]

Jenya7, не надо на этот бред внимания обращать, потому как даже фишки C99 не везде реализованы. Скажем, в том же sdcc объявлять переменные обязательно в самом начале функции.
Да и вообще, как правильно заметили выше, в embedded очень многое отличается от "компутерного" С.
И да, учитывая то, во что скатилась быдлохабра, категорически не рекомендую в этот рассадник вообще заходить. А то скатитесь до "одноклассников"…

[EvilWrecker]

Быдлохабра сейчас еще хуже стала, потому что интересные вещи, которые там когда-то можно было найти (как рисинку в ведре с дерьмом), перекочевали на какой-то "гиктаймс". А БХ теперь — тупо сборище поганой безмозглой вантузячьей школоты.
По делу: С — он и в Африке С. И писать на нем точно так же, как 30 лет назад. Ничего не изменилось.

и

Это компьютерный С-и , а встраиваемый С-и он совсем другой.
Для него больше половины что там написано либо не действительно, либо все делается наоборот.

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

[zltigo]

мелочь а приятно. буду править сорцы.

Бред полный. В первом примере бессмысленное говно в обеих случаях. Во втором инициализация через memset() и инициализация при объявлении локальной структуры ОТЛИЧАЮТСЯ.
Для достижения одинакового результата должно быть
struct thing localThing = {0,0};
"Советчики"
Да, и объявление структуры без типа, как в "примере" это как и водка без пива - деньги на ветер .
Да, статью по ссылке не читал и не буду - хватило "примеров".

[Сергей Борщ]

Вот если совсем коротко - в 2016 году надо писать на C++.

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

Для достижения одинакового результата должно быть
struct thing localThing = {0,0};

Забавно. В чем разница? Насколько помню, стандарт гарантирует инициализацию нулем неуказанных явно членов структуры. То есть достаточно было написать struct thing localThing = {};, а уж {0,0} - это совсем "масло масляное масляное"

Скажем, в том же sdcc объявлять переменные обязательно в самом начале функции.

Забавно. Призывать не использовать возможности, появившиеся в языке 16 лет назад, потому что какой-то sdcc их до сих пор не умеет. Гораздо правильнее в этом случае завязывать с пиками и выкидывать этот sdcc.

[zltigo]

Забавно. В чем разница? Насколько помню, стандарт гарантирует инициализацию нулем неуказанных явно членов структуры.

Локально, как в этом примере, создаваемых переменных и структур тоже???

[smalcom]

прочитал интересную статью. решил поделиться.

если хочется свеженького, то просто читайте новые возможности. к примеру отличия C99 и C11. Там уже много интересного и с правильными примерами.
С правильными потому, что

void initThing(void) {
memset(&localThing, 0, sizeof(localThing));
}

подразумевать, что это именно инициализация - неправильно. Это очистка. Для этого "программиста" - это может и "Классическая ошибка".

uint32_t b = input;

объявление в месте использования. это было в C++. Названо модненько lazy-чёто-там. Вся эта моднота бесит... Это просто объявление в месте использования, как "for(uint32_t i..."

Решил быть не таким категоричным как zltigo и пошёл по ссылке. Первые абзацы

Обычно вам подходит -O2, но иногда нужен -O3.Протестируйте оба варианта

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

[Сергей Борщ]

Локально, как в этом примере, создаваемых переменных и структур тоже???

А какая им разница? Если указано ={} то будут проинициализированны все элементы. Нулем. Даже неуказанные. Поэтому {0} уже избыточно, а {0, 0} - тем более. Я так себе понимаю. Или я не прав, и разница между ={0} и = {0, 0} все же есть? Тогда расскажите, какая.

Хотя... видимо был не прав. В случае {} компилятор ругается на неинициализированное поле. А вот в случае {0} ругани нет и обнуляются все поля. Так в чем же отличие {0} от {0, 0}, "критики"?

[zltigo]

А какая им разница? Если указано ={} то будут проинициализированны все элементы. Нулем. Даже неуказанные.

Для начала IAR находящийся под руками такое не скушал. GCC съел;

Поэтому {0} уже избыточно, а {0, 0} - тем более. Я так себе понимаю. Или я не прав, и разница между ={0} и = {0, 0} все же есть? Тогда расскажите, какая.

По логике вещей, для локальной стуктуры, котрая в отличие от статической глобальной не инициализируется, инициализируются только те члены, которые указали. Остальные, как и положено - мусор.
Попытался написать суперпрограммку для тестирования инициализации. Не удалось . Если что-то простое, то инициализации просто нет НИ В КАКОМ ВАРИАНТЕ, но можно заставить подсовывать компилятор 0, как некое возвращаемое значение из структуры, но можно заставить и мусор! Причем очень просто - объявляем неинициализируя стуктуру. При попытке возвратить какой-либо элемент - получаем законную ругань. Теперь присваиваем ( через =, в не при обьявлении) любому элементу какое-либо значение, возвращаем ДРУГОЙ и получаем дивный эффект - функция превращается в один возврат. То есть возвращаемое значение абсолютно произвольно, что собственно и написали
В общем дело темное, быстро не проверишь . На подкорку записал, может в выходные займусь изобретеним тестовой программки.

P.S.
Изобрел таки
В общем ситуация такова. При инициализации хоть одного элемента стуктуры компилятор ТУПО вызывает тот-же memset() на всяю структуру. При попытке проинициализировать хоть один элемент НЕ нулем, получается memcpy() всей стуктуры из ROM. Но "неициализированные" элементы при этом таки да - нули.
В общем вывод - если когда-то захочется проинициализировать только отдельные элементы локальной стуктуры, то нефиг пользоваться "автоматической" инициализацией - тупая она - жрет и ресурсы ROM и время.

[krux]

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

[zltigo]

не надо портить тех, кому суждено стать эмбеддерами, - подобной шелухой.

Вы не путаете эмбеддеров с Web программистами???

[ViKo]

Ну, одну пользу я уже извлек - char нужно произносить как "кар", в словаре посмотрел произношение character.

Еще одна - #pragma once

void processAddBytesOverflow(void *input, uint32_t len) {
...
вместо
void processAddBytesOverflow(uint8_t *bytes, uint32_t len) {
- не знаю, насколько это правильно, но на заметку можно взять

[krux]

Вы не путаете эмбеддеров с Web программистами???

молодежь как токарный станок - не имеет самоограничительных механизмов и имеет свойство наматывать на шкив всё что только может зацепиться.

[Сергей Борщ]

void processAddBytesOverflow(void *input, uint32_t len) {
...
вместо
void processAddBytesOverflow(uint8_t *bytes, uint32_t len) {
- не знаю, насколько это правильно, но на заметку можно взять

Не знаю что там делает processAddBytesOverflow, а вот send(void const *from, size_t len) или receive(void *to, size_t len) или dump(void const *from, size_t len) очень удобно:

Код

uint8_t A;
uint32_t B;
struct
{
    uint32_t Aa;
    .....
} C;
uint16_t D[8];
...
  dump(&A, sizeof(A));
  dump(&B, sizeof(B));
  dump(&C, sizeof(C));
  dump(&D, sizeof(D));

[Hexel]

господа программисты, прокомментируйте пожалуста вот это явление - стандарт безопасного написания кода
https://www.securecoding.cert.org/confluenc...Coding+Standard

зачем оно нужно, где применяется? я имею в виду это для embed, под винду, веб или в принципе для чего угодно?

может так надо писать коды в 2016? =)

[Dog Pawlowa]

прокомментируйте пожалуста вот это явление

Пожалуйста.
Первое же требование к препроцессору, указывать оба варианта #ifdef / #else абсолютно по делу.
Самый простой пусть избежать отправки заказчику прошивки с выключенным WDT, это указать
#else
#warning "WDT off!"
#endif

[Сергей Борщ]

прокомментируйте пожалуста вот это явление - стандарт безопасного написания кода
https://www.securecoding.cert.org/confluenc...Coding+Standard
зачем оно нужно, где применяется?

Почитал несколько пунктов. Все оказались из серии "не сушите кошек в микроволновке". Да, все они пишут правильно и именно так и надо делать, но разве кто-то делает иначе?

[Dog Pawlowa]

разве кто-то делает иначе?

Увы, и это ужас ужасный.
Мне приходится много работать с чужими проектами.
За месяцы! не удается выправить то состояния, пригодного для комфортного сопровождения и развития.
И проекты сложный, чтобы переписать все.
Насколько я понимаю, вы работаете один. Повезло.

[AlexandrY]

Мне приходится много работать с чужими проектами.
За месяцы! не удается выправить то состояния, пригодного для комфортного сопровождения и развития.
И проекты сложный, чтобы переписать все.

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

[zltigo]

Почитал несколько пунктов. Все оказались из серии "не сушите кошек в микроволновке". Да, все они пишут правильно и именно так и надо делать, но разве кто-то делает иначе?

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

[zltigo]

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

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

[smalcom]

NULL vs Nil

nullptr )

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

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

[Ga_ry]

Статью разбили в пух и прах.
Так как все таки писать на си в 2016, у кого-то есть идеи?

[AlexandrY]

Ну вы нашли о чем спорить! Чар или кар! Давайте лучше советы по собственно языку обсуждать.

Да сколько угодно.
Вот возьмем CMSIS OS, которую упорно продвигает ARM
Любители Keil RTX скоро должны обнаружить, что она не поддерживается на Cortex-M7
И всем массово надо будет переходить на CMSIS OS

Так вот там повсеместно используют конструкции типа

Код

#define osSemaphoreDef(name)  \
uint32_t os_semaphore_cb_##name[2] = { 0 }; \
const osSemaphoreDef_t os_semaphore_def_##name = { (os_semaphore_cb_##name) }
#endif

Вот мой совет на все времена: никогда не применять эту вот фигню - ##

Из-за нее не работает нормально рефакторинг, появляются скрытые имена, затрудняется отладка.
И все из-за того чтобы скрыть дополнительное объявление одной переменной от юзера. Это в опенсорсе то!

И вообще языки должны делится на корпоративные и индивидуальные, а не на высшие и низшие или отраслевые ( для WEB-а, для сенсоров, для ракет и т.д.)

[Dog Pawlowa]

Вот мой совет на все времена: никогда не применять эту вот фигню - ##

“Золотое правило жизни заключается в том, что нет никаких золотых правил”

Использую во всех проектах для кодирования состояний/функций/имен/текста в автоматах состояний.

[ViKo]

Вот возьмем CMSIS OS, которую упорно продвигает ARM
Любители Keil RTX скоро должны обнаружить, что она не поддерживается на Cortex-M7
И всем массово надо будет переходить на CMSIS OS

Не знаю, что за CMSIS OS, а CMSIS RTOS как появилась в виде надстройки над RTX, так я ее и использую.
http://www.keil.com/pack/doc/CMSIS/RTOS/html/index.html

[AlexandrY]

Использую во всех проектах для кодирования состояний/функций/имен/текста в автоматах состояний.

А показать?
Да, и второе правило от меня - минимум макросов.

Не знаю, что за CMSIS OS, а CMSIS RTOS как появилась в виде надстройки над RTX, так я ее и использую.
http://www.keil.com/pack/doc/CMSIS/RTOS/html/index.html

CMSIS OS это надстройка над любой OS , есть и над FreeRTOS.
А надстройка ну никак не может быть RTOS. Это качество определяет то что ниже надстройки.
А CMSIS-RTOS надо думать просто хитрый трейд-марк.

[Dog Pawlowa]

А показать?
Да, и второе правило от меня - минимум макросов.

Могу в личку выслать.
Да, недостатки известны, но преимуществ все-таки больше.
Яркий пример - offsetof.

[AlexandrY]

Могу в личку выслать.
Да, недостатки известны, но преимуществ все-таки больше.
Яркий пример - offsetof.

Не, в личку не катит. Здесь же публичное обсуждение.

[Dog Pawlowa]

Здесь же публичное обсуждение.

Короче, префиксы добавляются, чтобы получилось имя функции, номер в enum, и т.д.
Да чего объяснять, врага должны знать в лицо.

[smalcom]

Так как все таки писать на си в 2016, у кого-то есть идеи?

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

Вот мой совет на все времена: никогда не применять эту вот фигню - ##

зря. очень полезная вещь.

[Quasar]

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

[alexunder]

А где тут интересные моменты? Всегда считал данный ресурс местом сбора закомплексованных веб-дезигнеров разного пошиба,почему-то мнящих себя элитным сообществом(и разумеется таковым не являющимся), но весьма желающим быть генератором трендов в области языков/методологий программирования - почти что кузницей истин. Получается это у них подчеркнуто мерзко- в этом смысле по убогости с такими постами могут конкурировать разве что DIY проекты и печатные платы с гиктаймса. Особенно веселят персонажи предрекающие скорую гибель языкам группы C и тыкающие везде своими поделиями имеющими в названии слово java- ну а что с низ взять, с элитных веб-дезигнеров?

отлично сказано Удивляют личности, с гордостью свистящие во все стороны о том, что его/ее статья вышла на "хабре". Я еще могу понять подобное хвастовство если работу опубликовали в одном из журналов IEEE, но с каких пор этот гадюшник хабр стал референсом чего-либо?

[Guest_TSerg_*]

но с каких пор этот гадюшник хабр стал референсом чего-либо?

С момента свободы "свистежа" в общем гадюшнике Инет.

[nill]

Прилично пишут только немцы. Самый беспредел это ЮАР. Но и остальные не далеко ушли. Типична дивная помесь вдолбленных за период обучения вполне из себя правильных приемов программирования, какой то дикой безмозголой отсебятины и белых ниток которыми все это шито.

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

[zltigo]

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

Проекты коммерческие. Я другими не занимаюсь. Если говорить о том, что встречалось на просторах интернета, то когда-то очень давно, так давно, что уже и не помню, на меня в качестве хорошего примера, по крайней мере на тот момент времени, оказал проект Waterloo TCP/IP стек.

Там ссылка на Б. Страуструпа (вот еще задачка - как его имя и фамилию правильно произносить? ). Там говорится "чар", хотя ... Страуструп тоже не лингвист.

Ну, как минмум он общался с немалым количеством C/C++ программистов из разных стран и континентов , а как максимум, он АВТОР! и в своем праве.
И самое интересное, что значит "лингвист" в контексте языка Си? Где готовят Сишных филологов . Так что Страуструп это и есть ЛИНГВИСТ
Так что вопрос явно закрыт.

Знали бы вы больше одного языка (не включая вашего латышского) спокойней бы относились к стилю программирования.

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

[Herz]

Господа! К сожалению, ветка уклонилась в обсуждение нюансов произношения английских сокращений. Давайте придерживаться здесь основной темы. Всё постороннее выделил сюда.

[adnega]

Давайте придерживаться здесь основной темы.

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

[ViKo]

Изучая исходники с github, заметил, что в качестве основного рабочего объекта определяется одна глобальная структура, содержащая все переменные и указатели на функции. Далее в main создается эта структура и все манипуляции производятся с ней.

[smalcom]

Приведите пример, пжл. Как помне, то это не очень правильный подход для сложных программ.

[ViKo]

http://libopencm3.github.io/docs/latest/us...550c1c9f89d5748

[sigmaN]

Изучая исходники с github, заметил, что в качестве основного рабочего объекта определяется одна глобальная структура, содержащая все переменные и указатели на функции. Далее в main создается эта структура и все манипуляции производятся с ней.

http://libopencm3.github.io/docs/latest/us...550c1c9f89d5748

Кажется это немного не то о чем вы написали...Либо ваше описание немного не точное и сразу представляется что-то другое.
А по ссылке представлен классический пример того, как на Си реализуется объект и его методы. При этом программист передает методам ссылку на объект в явном виде.
В С++ это быо бы класс и описанные вами данные были бы закрытыми членами класса, а приведенные функции - публичным интерфейсом класса. При этом за кулисами происходит то-же самое - компилятор генерирует кучу функций и неявно передает им указатель на структуру с данными (*this).

Так что этот подход вполне валиден и стар как мир.

[ViKo]

Кажется это немного не то о чем вы написали...Либо ваше описание немного не точное и сразу представляется что-то другое.
А по ссылке представлен классический пример того, как на Си реализуется объект и его методы. При этом программист передает методам ссылку на объект в явном виде.
В С++ это быо бы класс и описанные вами данные были бы закрытыми членами класса, а приведенные функции - публичным интерфейсом класса. При этом за кулисами происходит то-же самое - компилятор генерирует кучу функций и неявно передает им указатель на структуру с данными (*this).

Так что этот подход вполне валиден и стар как мир.

Вот это и имел в виду. А в чем разница? Там надо пройтись по ссылкам, конкретно не выбирал, где описана сама структура.
http://libopencm3.github.io/docs/latest/us...rce.html#l00047
Может, и старо. Но я к этому подхожу лишь сейчас. Обусловлено сложностью проектов.
Си, вообще, старик, ничего нового ожидать не приходится.

[sigmaN]

Просто по вашему описанию и у меня и у smalcom, как я понял, сразу возникло впечатление что описывается какой-то "говнокод-подход" по глобализации всех переменных программы )) Что является тем еще злом!

[syoma]

Не знаю на счет веб дизайна и компьютерщиков, но помоему самые святые постулаты о том, как правильно писать на ембеддерном Си, пишет NASA в своих гайдлайнах и стандартах. Например http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf и аналогичные. И подходят они и к Си1980 и к Си2016.
Так как написаны почти кровью, а точнее предназначены для написания критически важного для миссий софта.
Как по мне маст ноу каждого начинающего ембеддерного программиста.
К ним еще MISRA-C:2004 можно добавить.

[sigmaN]

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

[smalcom]

описывается какой-то "говнокод-подход" по глобализации всех переменных программы

да, также подумал.

имхо тема как раз про красивое и/или надёжное программописание. Т.е. не для мигалки. Потому что быдлокодить можно внезависимости от эпохи и языка. Если честно - я так и не понял чего хочет ТС, плюс немного тема привлекла софистов. MISRA - это плюс. Как я вижу процесс обучение - сначала учим правила, выводим закорючки, а когда всё это "отскакивает от зубов" - балуемся эрративом.

С ПО нужно провести такую-же аналогию. MISRA надо там где надо )

абсолютно в дырочку: одна из задач инженера - минимизировать расход ресурсов при выполнении той же задачи


будучи "малышом" я так свой первый втык получил: при ремонте на объекте запаниковал и заменил нерабочее реле новым... стоимостью 15 кредитов. Хотя рядом был радиобазар и можно было прикупить нужное за 1-2 кредита.

[demiurg_spb]

libopencm3

Раз уж затронули эту либу...
Меня лично напрягает их подход:
для работы с периферией используется номер (например номер UART: void usart_set_baudrate (uint32_t usart, uint32_t baud)), а у меня все мои либы используют обычно указатель на хэндл того же UART.
Что, на мой взгляд гораздо прямее, т.к. не нужны никакие if-else по номеру, а сразу usart->sfr.BRR =XX.
Именно поэтому я до сих пор не использую libopencm3, хотя идея прекрасная и code-style правильный...

[AlexandrY]

И подходят они и к Си1980 и к Си2016.

О тут бы не согласился.
Стиль языков это отражение свойств редакторов, библиотек и средств разработки этих языков.
Очевидно же что пишущий в Notepad (что в прошлом и было) будет пропагандировать совсем другой стиль чем пишущий в Visual Studio с установленным Visual Assist.
Совершенствуются средства разработки и соответственно меняется стиль. Причем в корне.

Насчёт той же MISRA заморачиваться можно только если все пишете сами с нуля. Чуть сторонняя библиотека и можете MISRA отключать.

С другой стороны есть такие статические анализаторы как С-STAT у IAR. Крутейшая вещь. Никакой MISRA не надо.
Это тоже отправляет добрую часть старых рекомендаций в топку. С-STAT всё сам найдет и укажет что исправить.

Короче в 2016 будет продолжаться ослабление требований к стилям и усиливаться индивидуализация кодирования. То что некоторые называют "говнокодом". Хотя, надо бы банить за применение такого определения.

[sigmaN]

То что некоторые называют "говнокодом". Хотя, надо бы банить за применение такого определения.

Т.е. книгу М.Фаулера Рефакторинг вы тоже не рекомендуете? А ведь там как раз вполне серьезно вводится понятне code smells и даже проводится аналогия с детскими пеленками кажется ))))

Нет уж. Говнокод это как раз таки абсолютно обоснованное понятие. И это не то-же самое, что разные стили оформления кода(на что будет влиять упомянутый Visual Studio с Visual Assist). В процессах построения ПО уже все хорошо изучено и изложено. Каталогизировано по степени запаха. И даже с примерами. Реально тот-же Фаулер прямо четко и конкретно указывает какие признаки обладают дурными запахами и что можно сделать и почему это нужно сделать(примеры из разных жизненных ситуаций почему проект потом в это упирается).

для работы с периферией используется номер (например номер UART: void usart_set_baudrate (uint32_t usart, uint32_t baud)), а у меня все мои либы используют обычно указатель на хэндл того же UART.
Что, на мой взгляд гораздо прямее, т.к. не нужны никакие if-else по номеру, а сразу usart->sfr.BRR =XX.

Ну тут можно поспорить. С точки зрения принципов сокрытия информации тут как раз лучше подходит абстракция порта до номера, а не предлагать таскать везде этот указатель на структуру(хэндл) порта. Эта структура по идее вообще должна как можно реже всплывать и находиться в кишках HALа ибо есть ни что иное как способ представления порта внутри HALa. Наружу выводится интерфейс. Просто Си не позволяет сделать это естественным образом и часто таки заставляет программиста таскать с собой хэндл, но это уже другая история... Но если хэндл пользователю либы не виден и ввели номер - это архитектурно правильное решение я считаю!

if-else по номеру, а сразу usart->sfr.BRR =XX.

опять же классики учат вначале строить систему максимально правильно(сюда входит и принцип сокрытия информации) а после профилирования устранить узкие места. Если например в коде будет встречаться какой-нибудь uart_send(uint32_t usart, char* string); и эта функция будет дергаться так часто, что упомянутый if-else реально начнет влиять на производительность то например можно будет его упразднить путем добавления функции usart1_send(char* string); где будет прямое обращение к хэндлу порта. Однако же я сомневаюсь что до этого дойдет в данном случае(ибо usart медленный).

[zltigo]

Короче в 2016 будет продолжаться ослабление требований к стилям и усиливаться индивидуализация кодирования. То что некоторые называют "говнокодом". Хотя, надо бы банить за применение такого определения.

"Говнокодирование" и "индивидуальный стиль кодирования" это две абсолютно разные вещи. Одна другую не отменяет и не заменяет. Попытки прикрыть говнокодирование разговорами за "индивидуальный стиль" я бы назвал первейшим признаком говнокодера.

Ну тут можно поспорить. С точки зрения принципов сокрытия информации тут как раз лучше подходит абстракция порта до номера, а не предлагать таскать везде этот указатель на структуру(хэндл) порта.

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

Эта структура по идее вообще должна как можно реже всплывать....

Всплывать или не всплывать это уже дело второе и не зависит от того, как выгдядит обращение к этой структкре. Но если используется номер порта, то добраться до любого эдемента стукруры можно только через пересчет номера порта в адрес этой же структкры. Лишние телодвижения, тогда когда в случае "хендла" доступ к, напимер, посмотреть на какой нибудь флаг статуса может быть вообще макросом разворачивающися в одну команду. "Номер порта" абсолютно ненужный ЛИШНИЙ уровень абстракции в подавляющем большинстве случаев.
Хотя опять-же какой к черту номер порта это уровень абстракции? Никакая это не абстракция - это антиабстакция, ибо когда Вы о нем говорите над Вами довлеет абсолютно ральный физический порт UART. А вот "хэндл" есть самая, что ни на есть абстракция - за ним уже может с неменьшим успехом стоять и гигабитный эзернет в качестве физического уровня.

[AlexandrY]

Т.е. книгу М.Фаулера Рефакторинг вы тоже не рекомендуете? А ведь там как раз вполне серьезно вводится понятне code smells и даже проводится аналогия с детскими пеленками кажется ))))

Фаулер во-первых пишет про Яву, во-вторых он пишет приложения автоматизации бизнеса, в третьих он пишет, похоже, в том самом notepad-е.
Т.е. с моей точки зрения ссылка на него не в тему.

"Говнокодирование" и "индивидуальный стиль кодирования" это две абсолютно разные вещи. Одна другую не отменяет и не заменяет. Попытки прикрыть говнокодирование разговорами за "индивидуальный стиль" я бы назвал первейшим признаком говнокодера.

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

[zltigo]

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

Любая проблема сначала должна быть четко и однозначно сформулирована. Если проблема заключется в том, что написаное является говном, то это так и надо называть, а не "индивидуальным стилем кодирования". Замена слова "говнокод" эвфемизмами на, например, "код написанный альтернативно одаренным талантом с ярко выраженным индивидуальным стилем кодирования", сути проблемы, увы, не меняет .
Говнокод на самом деле может по нынешним временам писаться не только конечным программистом, но и всякими "визардами" или притаскиваться в "библиотеках". Относительно недавно делал рефакторинг говнокода. Те, кто его родил мне знакомы по работе и в общем случае говнокодерами совершенно не являются. Но, одно но. Контроллер был кипарисовский PSoC. C железом там работать тяжело, посему кипарисовцы радостно навязывают использование визарда. Визард генерит великолепно стилистически выверенный говнокод. Дальше выбор, либо лепить из этого говна, либо нет. Из говна конфетку не сделаешь, зато быстро. Сделали быстро. Нет все заработало и работало годами. Только вот количество оборудованя в системе росло, росло и выросло до того, что система стала захлебыватся по пропускной способности канала связи с сервером. Причем канал-то как-бы и достаточный, но есть одна проблема он эфирный, посему сбои, посему на запросы сервера могут и не ответить, посему таймауты. Так вот в таймаутах-то дерьмо в вылилось. Говнокод из говнкогда был сделан так, что ответы на запросы сервера были не самые приоритетные, посему таймауты вынужденно большими. Как только количество оборудования с течением времени увеличили и уровень ошибок возрос, то все и встало колом.
Ответить быстро на запрсы сервера не получалось, потому, что из визадовсково говнокода даже хотя-бы примитивно построенную системку на вложенных прерываниях не построить.
Пришлось говнокод чистить.

[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 реализация этой библиотеки будет на много проще и компактнее.

[zltigo]

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

От того, что добираться будет "дравер порта" или кто-то другой в другом месте совершенно ничего не изменится, ибо ДОБИРАТЬСЯ по любому придется. И вопрос в том, что будет
представлять собой этот самый запрос GetTXCompleteFlag() - одну команду, или дивнонавороченную функцию для начала бегающую по заранее созданным структурам жрущим еще и память.

И таки никто не говорит, что сопоставление номера к регистру или вычисление адреса должно непременно происходить на этапе выполнения программы )

Ага. Можно постараться и нагородить говнокода для того, что-бы "9" на этапе компиляции вдруг превратилось в, например, указатель на слово флагов. Зачем только?

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

Это у Вас в голове сидит тупой BIOS писишки в котором в 70x годах тупо забили 4 порта, заняли память под 4 структуры даных для этих портов и родили абстракцию "COM1..4" для неведомых приложений.
P.S.
Написал про писишку и понял, что на самом деле есть два РАЗНЫХ взгляда на абстракцию инерефейса.
Один со стороны ЖЕЛЕЗА - есть железка, к нее есть 9 UART, заводим под них массив струкур данных, пишем какие-то функции и все. С точки зрения железячника родившего в меру своего пониманя драйвер для своей железки, это достаточный уровень абстракции.
Второй подход со стороны СИСТЕМЫ, которая вообще изначально ничего ни о каких 9 UART ни на каких конкретных контроллерах не знает и знать не обязана.
Я уже десятилетия смотрю на железо, как создатель систем, хотя в общем железячник до мозга костей. Будем считать, что эвоюционировал .
Так что еще раз, с еще большей уверенностью, повторю - обращение к UART по номерам это на самом деле АНТИабстракция.

P.P.S.
У меня лет 20 уже тому назад в одной моей системе системный вызов драйвера предающего фрейм в какой-то COM порт эволюционировал до передачи фрейма _устройству_выполняющему_в системе_заданную_функцию_ вот это уже можно называть абстракцией .



И, прошу меня извинить, больше я ничего на эту тему писать не буду. Времени жалко

[sigmaN]

Ага. Можно постараться и нагородить говнокода для того, что-бы "9" на этапе компиляции вдруг превратилось в, например, указатель на слово флагов. Зачем только?
то у Вас в голове сидит тупой BIOS писишки в котором в 70x годах тупо забили 4 порта

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

Вот это 2016 год я считаю.

[zltigo]

Нет, у меня в голове сидит драйвер порта....

http://electronix.ru/forum/index.php?showt...t&p=1400346
Прочитайте P.S.

[sigmaN]

У меня лет 20 уже тому назад в одной моей системе системный вызов драйвера предающего фрейм в какой-то COM порт эволюционировал до передачи фрейма _устройству_выполняющему_в системе_заданную_функцию_ вот это уже можно называть абстракцией

Ну это разные вещи. Вы абстрагировались таким образом от интерфейса предачи вовсе и ввели в систему некое устройство, выполняющее функции связи и способное передать ваш фрейм. Ниже там же всё равно оно в УАРТ полезет... или в эзернет...
Точно так-же как и вы говорите что номер порта это не абстракция т.к. оно потом полезет по номеру в конкретную структуру.
Улавливаете забавную аналогию? ))))

P.S.
zltigo, я с большим уважением отношусь к Вам и помню как много реально полезных советов вы мне давали на этом форуме, так что не сочтите за наглость или спор ради спора. Просто реально любая абстракция делающая удобства для увровня выше создает дополнительную нагрузку для уровня ниже, который эту абстракцию должен превращать во что-то реально. В этом смысле все абстракции одинаковы и тем не менее, не смотря ни на что, повсеместно используются ибо это один из главных способов управления сложностью(опять же по Макконнеллу). И именно в контексте управления сложностью и возникает идея инкапсуляции и сокрытия данных и реализации. О которой я и толкую, приводя конкретные примеры реализации.

[zltigo]

так что не сочтите за наглость или спор ради спора.

Все нормально! Никаких проблем.

Просто реально любая абстракция делающая удобства для увровня выше создает дополнительную нагрузку для уровня ниже, который эту абстракцию должен превращать во что-то реально

Вот именно по этой причине и надо думать, как конкретно абстракцию реализовывать. Реализация абстракции для UART "по номеру порта" и в этом и во всех других отношениях НЕУДАЧНА да и абстракцией не является, поскольку тупо пытается отражать реальность ввиде какого-то числа UART.