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

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

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

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

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

или

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

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

и



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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Еще одна - #pragma once

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) очень удобно:

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

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

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

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

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

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

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

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

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

nullptr )


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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




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




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

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

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

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

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

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

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

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

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

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

Не знаю на счет веб дизайна и компьютерщиков, но помоему самые святые постулаты о том, как правильно писать на ембеддерном Си, пишет 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 можно добавить.

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