[Arlleex 131]

В 04.08.2023 в 12:42, razrab83 сказал:

какой-то идиот сделал там галочку считать char беззнаковым. По дефолту в си он знаковый.

Ну вот прям ни разу нет.

В 04.08.2023 в 12:42, razrab83 сказал:

Ещё одна говноособенность иара... неинициализируемая переменная без явных указаний инитится нулём.

Глобальная? Тогда все ок.

В 04.08.2023 в 12:42, razrab83 сказал:

Стандарт СИ оговаривает такой код, делает неявное приведение и делает сравнение. Мне когда на собеседе дали такую задачу и спросили "-В иф зайдет?", я сказал, "-Я не знаю правильный ответ, но это говнокод. Так писать нельзя и я так не пишу. Если я встречу такой код, я открою справочник, посмотрю куда преобразует СИ и сделаю ЯВНОЕ приведени типа."

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

В 04.08.2023 в 12:42, razrab83 сказал:

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

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

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

В 04.08.2023 в 13:10, razrab83 сказал:

Причем, он уверен, что си именно так работает и так задумано. Он считает, что в СИ очерёдность инклуде строгая, и если её не соблюдать, то код не соберётся.

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

[Arlleex 131]

2 часа назад, ericN сказал:

Не должен зависить результат сборки от последовательности include. 

Кому не должен? Вы откройте, например, исходники FreeRTOS, удивитесь, как там переопределяются неполные типы в полные.

[Arlleex 131]

5 часов назад, dimka76 сказал:

Ну, сейчас начнется 

Ну, таких "приколов" между Си и плюсами вагон и телега.

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

В новых плюсах, например, конструкция типа volatile a; a |= ...; уже не рекомендуется и компилятор будет материться.

[haker_fox 60]

4 hours ago, razrab83 said:

У большинства МК-прогерров нет ни какой культуры написания ПО. Я не знаю как сейчас, может плотно учать в ВУЗах программированию, но опотные мк-си-прогеры - это какойто треш!!

Как модератор делаю Вам устное замечние: научитесь быть сами культурным. На форуме принят русский язык для общения. Это закреплено в правилах. У Вас же сплошная каша из слов в сообщении: ни знаков препинания; ни начала, ни конца предложения. И ругать IAR некрасивыми словами, сами знаете какими, здесь тоже не надо без веских аргументов.

[x893 35]

1 hour ago, Arlleex said:

В новых плюсах, например, конструкция типа volatile a; a |= ...; уже не рекомендуется и компилятор будет материться.

Совершенно правильно "будет материться".

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

[Arlleex 131]

35 минут назад, x893 сказал:

Совершенно правильно "будет материться".

Описка у меня там - тип забыл. Например, u32.

А насчет правильности - вопрос спорный, настолько спорный, что материться компиляторы стали, если память не изменяет, аж только в C++20.

И на разных ресурсах и около-комитетных тусовках народ взвыл, т.к. куча заголовков и исходников, написанных за тучу лет, идут лесом.

Т.е. комитет требует

u32 volatile a;

a |= 1 << 5; // deprecated in C++20

a = a | 1 << 5; // ok

Хотя по стандарту составная запись гарантирует, что левый операнд будет вычислен один раз, в отличие от второй формы записи.

Вот и подожгло у сообщества из-за совершенно нелогичного требования.

[tonyk_av 31]

8 hours ago, haker_fox said:

ЕМНИП, эту рекомендацию давал уважаемый @zltigo лет так 10 назад на форуме🙂 Я дополнительно пользуюсь CppCheck или/и встроенным в IAR статическим анализатором.

Реализации С++ для ряда МК появились относительно недавно, поэтому и возможности сравнить не было. А тут работал с кросс-платформенным проектом, да ещё и переносил из С в С++, поэтому была возможность сравнить работу разных компиляторов и разных языков.

[repstosw 18]

Ещё один недостаток IAR.

При портировании библиотек libjpeg и libspeexdsp и сборки общего проекта, линковщик выдаёт ошибку: не определены функции:

__close, remove, __lseek, __read, __open

Хотя я нигде их не использую. И вызываю библиотечные функции (из libjpeg, libspeexdsp), которые не работают с файловым вводом-выводом.

Тем не менее, линковщик считает, что они нужны.   Почему ?

Как в IAR включить вырезание всех неиспользуемых функций?  В GCC это делается легко.

Пробовал включать семихостинги всякие(в Ире), в итоге, программа заваливалась в Abort.

Всё кончилось тем, что я написал свою затычку для IAR:

//File I/O gag

int __open(const char *filename,int access,unsigned mode)
{
 return -1;
}

int __close(int fd)
{
 return -1;
}

int __read(int fd,void *buf,unsigned count)
{
 return -1;
}

long __lseek(int handle,long offset,int origin)
{
 return -1;
}

int remove(const char *fname)
{
 return -1;
}

 

И программа перестала валиться в Abort.

В GCC не нужно писать никаких заглушек.

 

И всё-же, как более элегантнее и правильнее разрулить эту ситуацию?

Изменено 5 августа, 2023 пользователем repstosw

[ericN 3]

В 04.08.2023 в 18:19, Arlleex сказал:

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

ммдааа... это сразу вас показывает - что вы за программист, если вы пишете код, который зависит от порядка следования инклудов..

[juvf 10]

В 04.08.2023 в 18:36, Arlleex сказал:

Вы откройте, например, исходники FreeRTOS,

пруф или.... покажите конкретный пример, где в FreeRTOS сборка зависит от порядка инклудов?

 

[x893 35]

17 hours ago, Arlleex said:

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

Это только у гуру программирования. У нас, начинающих, пофиг.

[razrab83 17]

18 часов назад, Arlleex сказал:

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

Да конечно! Расскажите тем, кто пользуется автоматическим форматированием кода, или авторам clang format. Сlang format расставляет инклуде так, чтобы удобно было читать программисту, группирует их, делает очень аккуратный и красивый код. И вот clang format вас точно не спросит, в какой последовательности расставлять инклуде.

18 часов назад, Arlleex сказал:

У меня тоже пока не всегда выходит

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

[Arlleex 131]

5 часов назад, ericN сказал:

ммдааа... это сразу вас показывает - что вы за программист, если вы пишете код, который зависит от порядка следования инклудов..

Раз тут такой ажиотаж вокруг фриртоса - вот пруфы, пожалуйста.

4 часа назад, juvf сказал:

пруф или.... покажите конкретный пример, где в FreeRTOS сборка зависит от порядка инклудов?

Сюда же (выше ссылка). Переместите включение, например, task.h перед FreeRTOS.h и соберите.

 

2 часа назад, x893 сказал:

Это только у гуру программирования. У нас, начинающих, пофиг.

 

1 час назад, razrab83 сказал:

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

Вы, для начала, с глобальными переменными разберитесь.

Затем,

Цитата

И вот clang format вас точно не спросит, в какой последовательности расставлять инклуде.

глядишь, и об опции SortIncludes -> false узнаете.

[Arlleex 131]

7 часов назад, repstosw сказал:

В GCC не нужно писать никаких заглушек.

В кейле тоже пишем - даже документация требует при переходе на 6 компилятор.

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

В IAR, думаю, ситуация похожа.

[xvr 12]

21 hours ago, Arlleex said:

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

В общем случае не должен, но могут быть исключения. Например предкомпилённые хидеры - они собираются в один инклюд, который ДОЛЖЕН включаться первым во все единицы компиляции.

Но даже в этом случае ХИДЕРЫ лучше делать полностью независимыми друг от друга. Более того, в некоторых случаях могут быть эксцессы, например в Qt проектах есть тул, который запускается автоматом и создаёт исходники для поддержки RTTI, в них никакие общие хидеры не включаются и порядок включения других хидеров не гаратируется, так что незвисимость всего, что в него попадает - must have.

 

Если же по каким то причинам необходимо выдерживать порядок инклюдов (не спрашивайте по каким именно 🙂 ), то это ОБЯЗАТЕЛЬНО должно быть отражено в проектной документации и очень желательно в самих хидерах (например отслеживать порядок включения внутри хидера и ругаться, что именно и где забыли включить).

Програмист должен заниматься программированием, а не сыскной работой 🙂