Вопросы по С/С++ (СИ)

[Apparatchik]

VladislavS писал(а):

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

Да, речь о микроконтроллере. Посмотрел на этот пример и заинтересовался почему структура fno статическая. Раз она одна на все рекурсии, то видимо для экономии памяти при глубоких рекурсиях.

[ARV]

От варнингов нужно избавляться всегда.

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

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

[ПростоНуб]

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

[arkhnchul]

ARV писал(а):

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

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

[Eddy_Em]

Кстати, свежие gcc (8 и 9) довольно-таки круты: добавили очень много разных полезных проверок. Правда, выхлоп до сих пор сильно отстает от шланговского (благо, можно, не собирая шлангом, использовать его как лексический анализатор в qt-creator'е; но вот шланг почему-то не любит вложенные функции, а я их люблю). Зато пришлось в старый код втыкать уйму вещей: скажем, теперь выдается ошибка (просто я всегда собираю с -Wall -Werror -Wextra) на fallthrough в switch(). И приходится добавлять __attribute__ ((fallthrough)) в нужных местах (а то и макрос определять, если собираться это будет в разных версиях gcc)...
И к некоторым другим вещам строже стали относиться. Сижу вот, перелопачиваю чужой код, который на gcc4 без -Werror собирался, а на девятом отказывается. Да еще и приходится стиль c-89 на c-99 и позже переписывать.

[jcxz]

ПростоНуб писал(а):

jcxz, тут я с Вами не согласен. Простейший пример. Имеем таблицу указателей на функции. Пусть у функции один параметр. Причем части функций этот параметр просто не нужен, хотя остальные функции без него обойтись не могут. Получаем два варианта решения:
1. Игнорируем конкретное предупреждение о неиспольуемом значении параметра:

А в чём несогласны-то и почему? И зачем игнорировать если мы точно знаем что вызываем правильно - значит можно просто привести указатель к нужному типу и избавиться от варнинга.

Добавлено after 1 minute 46 seconds:

ПростоНуб писал(а):

Здесь обработчками ir_handler_pgm_prev(), ir_handler_pgm_next() и ir_handler_switch_channel() код нажатой кнопки на ИК пульте совершенно не нужен, тогда как обработчиками ir_handler_brightness() и ir_handler_pgm_no() он необходим.

Да - а ещё бывают значения аргументов "по-умолчанию". Как раз для такого случая.

Добавлено after 1 minute 32 seconds:

GARMIN писал(а):

Не знаю, насколько кошерно было моё решение, но я в подобном случае обьявлял статическую переменную с параметром команды. Или в моём случае статическую структуру с несколькими параметрами. Так я избавился от неоднозначности вызова.

Это очень кривое решение. Так как функция становится нереентрантной и потоко-небезопасной. На ровном месте.

[WiseLord]

Я обычно просто пишу в начале тела функции (void)unused_variable; - вполне достаточно, чтобы предупреждения исчезли. Если в дальнейшем в функции переменная unused_variable всё-таки понадобится - это просто убирается.

[jcxz]

ПростоНуб писал(а):

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

...и даже при всём при этом никто не мешает использовать для них операцию приведения типа чтобы положить все указатели в один массив.
Не понимаю - в чём проблема?

[Eddy_Em]

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

Код:

#define _U_    __attribute__((__unused__))

Тогда [временно] ненужные аргументы обозначаются просто:

Код:

type function(_U_ int arg1, _U_ int arg2, double arg3)...

[ПростоНуб]

jcxz писал(а):

ПростоНуб писал(а):

jcxz, тут я с Вами не согласен. Простейший пример. Имеем таблицу указателей на функции. Пусть у функции один параметр. Причем части функций этот параметр просто не нужен, хотя остальные функции без него обойтись не могут. Получаем два варианта решения:
1. Игнорируем конкретное предупреждение о неиспольуемом значении параметра:

А в чём несогласны-то и почему? И зачем игнорировать если мы точно знаем что вызываем правильно - значит можно просто привести указатель к нужному типу и избавиться от варнинга.

Вы вообще о чем? О каком указателе и о каком типе речь?

[jcxz]

ПростоНуб писал(а):

Вы вообще о чем? О каком указателе и о каком типе речь?

А Вы о чём? Я о вашем комменте моего поста. С рассказом про разные указатели на функции. Не вижу там причин почему не нужно избавляться от варнингов.

[arkhnchul]

Eddy_Em писал(а):

приходится добавлять __attribute__ ((fallthrough)) в нужных местах (а то и макрос определять, если собираться это будет в разных версиях gcc)

его комментарием можно подавить

Код:

switch(foo){
    case FOO_VAL1:
        do_something1();
        break;
    case FOO_VAL2:
        do_something2();
        // FALLTHROUGH
    case FOO_VAL3:
        do_something3();
    default:
        do_default_stuff();
}

https://gcc.gnu.org/onlinedocs/gcc/Warn ... allthrough

Спойлер

it is also possible to add a fallthrough comment to silence the warning. The whole body of the C or C++ style comment should match the given regular expressions listed below. The option argument n specifies what kind of comments are accepted:

-Wimplicit-fallthrough=0 disables the warning altogether.
-Wimplicit-fallthrough=1 matches .* regular expression, any comment is used as fallthrough comment.
-Wimplicit-fallthrough=2 case insensitively matches .*falls?[ \t-]*thr(ough|u).* regular expression.
-Wimplicit-fallthrough=3 case sensitively matches one of the following regular expressions:
-fallthrough
@fallthrough@
lint -fallthrough[ \t]*
[ \t.!]*(ELSE,? |INTENTIONAL(LY)? )?
FALL(S | |-)?THR(OUGH|U)[ \t.!]*(-[^\n\r]*)?
[ \t.!]*(Else,? |Intentional(ly)? )?
Fall((s | |-)[Tt]|t)hr(ough|u)[ \t.!]*(-[^\n\r]*)?
[ \t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?
fall(s | |-)?thr(ough|u)[ \t.!]*(-[^\n\r]*)?
-Wimplicit-fallthrough=4 case sensitively matches one of the following regular expressions:
-fallthrough
@fallthrough@
lint -fallthrough[ \t]*
[ \t]*FALLTHR(OUGH|U)[ \t]*
-Wimplicit-fallthrough=5 doesn’t recognize any comments as fallthrough comments, only attributes disable the warning.

The comment needs to be followed after optional whitespace and other comments by case or default keywords or by a user label that precedes some case or default label.

[ПростоНуб]

Eddy_Em, проблема в том, что это исключительно конструкция GCC. В стандарте даже упоминания о таком нет. Тогда как #pragma стандартом специально зарезервирована для подобных применений. Если потребуется, например, на Clang переползать, что делать будете?

Добавлено after 39 seconds:
jcxz, хватит смешить народ и прочитайте, что написал я, а куда понесло Вас )))

[VladislavS]

Открываем стандарт С++17. Проблема ПростоНуб рашается [[maybe_unused]], а проблема Eddy_Em через [[fallthrough]]. И если для STM8 я могу понять "страдальцев", то тех кто сидя на GCC жалуется ну никак не понимаю.

[arkhnchul]

сидя на gcc все равно хорошо бы писать переносимые конструкции.

[VladislavS]

С++17 для ARM поддерживает не только GCC.

[arkhnchul]

для ARM.
ну и мы вроде как про C говорим, нет?)

[VladislavS]

В теме запрещены разговоры про С++? Я просто смотрю на проблему с другой стороны.

[Eddy_Em]

VladislavS писал(а):

Открываем стандарт С++17.

При чем здесь кресты? Эмбеддеры на крестах не пишут! Кресты нужны исключительно для создания GUI на ненужной Qt!

[ПростоНуб]

VladislavS, я же Вам уже писал, что C++17 для продуктива пока не готов. Не надо бежать впереди паровоза. И мои проблемы не надо решать, так как я их давно решил при помощи pragma, что совместимо даже с C89/90.