VladislavS, что значит "не принимает"? Я не понимаю Вашей терминологии.
Я вел речь только о тех случаях, когда один или несколько параметров функции не используются ей именно в целях унификации вызова в машинных кодах, увеличивая производительность кода и уменьшая его размер. Тогда как перегрузка в подобных случаях приводит к обратному - к увеличению размера кода и понижению быстродействия, так как компилятор уже не может развернуть такой код в таблицу вызовов функций.
ПростоНуб, можно и разное количество аргументов делать, но для этого придется с va_args заморачиваться, что жрет ресурсы... Проще уж написать __attribute__((unused)) на неиспользуемые функциями аргументы.
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
SDCC - вообще жутчайший компилятор! Оптимизацией там вообще не пахнет, иной раз как глянешь листинг - жесть! Приходится местами вручную оптимизировать (а то и ассемблерные вставки делать).
Но, к сожалению, порта gcc для STM8 нет, и приходится кривым sdcc собирать (больше-то компиляторов и нет под этот МК).
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Eddy_Em, и не только для STM8. Для ряда МК он или единственный, или лучший вариант.
На самом деле, начиная с 3.8 оптимизацией там запахло. Даже 3.7 после 3.6 показалась манной небесной )
По крайней мере, уже начиная с 3.7 особого смысла использовать вместо SDCC COSMIC или IAR не стало.
Подскажите пожалуйста: если локальную переменную объявить как static то ее значение сохраняется при выходе из функции. Но что будет если эту функцию вызывать рекурсивно? Будет выделятся память по мере вызовов и сохранятся? Интересует на языке Си.
Apparatchik, статическая переменная размещается в статическом сегменте памяти, где память для не выделяется компилятором (в некоторых специфичных случаях - компоновщиком). Поэтому откуда бы Вы к ней не обращались, физически будете обращаться по одному и тому же адресу памяти.
[uquote="VladislavS",url="/forum/viewtopic.php?p=3712021#p3712021"]Прикольно. Чисто алгоритмически не важно это одна или много переменных, а за стек переживаем?[/uquote]
Да, речь о микроконтроллере. Посмотрел на этот пример и заинтересовался почему структура fno статическая. Раз она одна на все рекурсии, то видимо для экономии памяти при глубоких рекурсиях.
jcxz писал(а):От варнингов нужно избавляться всегда.
предела совершенству нет, но свобода воли присутствует всегда.
мы и дорогу не сегда переходим по зебре, и на красный свет, порой, перебегаем... оно то, конечно, не правильно, но можно
избавиться от многих варнингов нельзя в принципе. например, множество сторонних библиотек для функций указывают параметры типа char*, а я частенько это дело нарушаю и передаю uint8_t* или даже int8_t* . бывает и наоборот. и единственный способ избежать варнинга - тупо кастовать типы, а вот это самое я считаю более вредным и опасным, чем варнинги.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
ARV, как раз явно преобразовать тип является признаком хорошего стиля. Только не надо это делать тупо )))
А вот в приведенном мной примере все варианты, кроме явного подавления предупреждения, увеличивают размер кода и понижают его производительность.
В общем случае, если в ночной сборке транка есть предупреждения - автор кода получит по шапке. Это уже без вариантов )
[uquote="ARV",url="/forum/viewtopic.php?p=3712028#p3712028"]множество сторонних библиотек для функций указывают параметры типа char*, а я частенько это дело нарушаю и передаю uint8_t* или даже int8_t* . бывает и наоборот. и единственный способ избежать варнинга - тупо кастовать типы[/uquote]вот и надо кастовать.
с варнингами такое дело - они на самом деле выдаются не просто так, а как указание, что возможно программист делает какую-то фигню. И ему предлагается либо подтвердить "да, я знаю, что делаю" - кастом, явным подавлением именно этого предупреждения или еще как - или разобраться и понять, что да, хрень придумал. И вот последний случай затруднителен, если там стопицот предупреждений, воспринимаемых в стиле "да там каста просто нет, ерунда, нормально же работает". Ну, мальчик слишком часто кричал "Волк!", а дальше мы знаем
Кстати, свежие gcc (8 и 9) довольно-таки круты: добавили очень много разных полезных проверок. Правда, выхлоп до сих пор сильно отстает от шланговского (благо, можно, не собирая шлангом, использовать его как лексический анализатор в qt-creator'е; но вот шланг почему-то не любит вложенные функции, а я их люблю). Зато пришлось в старый код втыкать уйму вещей: скажем, теперь выдается ошибка (просто я всегда собираю с -Wall -Werror -Wextra) на fallthrough в switch(). И приходится добавлять __attribute__ ((fallthrough)) в нужных местах (а то и макрос определять, если собираться это будет в разных версиях gcc)...
И к некоторым другим вещам строже стали относиться. Сижу вот, перелопачиваю чужой код, который на gcc4 без -Werror собирался, а на девятом отказывается. Да еще и приходится стиль c-89 на c-99 и позже переписывать.
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3711925#p3711925"]jcxz, тут я с Вами не согласен. Простейший пример. Имеем таблицу указателей на функции. Пусть у функции один параметр. Причем части функций этот параметр просто не нужен, хотя остальные функции без него обойтись не могут. Получаем два варианта решения:
1. Игнорируем конкретное предупреждение о неиспольуемом значении параметра:[/uquote]
А в чём несогласны-то и почему? И зачем игнорировать если мы точно знаем что вызываем правильно - значит можно просто привести указатель к нужному типу и избавиться от варнинга.
Добавлено after 1 minute 46 seconds:
[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3711925#p3711925"]Здесь обработчками ir_handler_pgm_prev(), ir_handler_pgm_next() и ir_handler_switch_channel() код нажатой кнопки на ИК пульте совершенно не нужен, тогда как обработчиками ir_handler_brightness() и ir_handler_pgm_no() он необходим.[/uquote]
Да - а ещё бывают значения аргументов "по-умолчанию". Как раз для такого случая.
Добавлено after 1 minute 32 seconds:
[uquote="GARMIN",url="/forum/viewtopic.php?p=3711930#p3711930"]Не знаю, насколько кошерно было моё решение, но я в подобном случае обьявлял статическую переменную с параметром команды. Или в моём случае статическую структуру с несколькими параметрами. Так я избавился от неоднозначности вызова.[/uquote]Это очень кривое решение. Так как функция становится нереентрантной и потоко-небезопасной. На ровном месте.
Я обычно просто пишу в начале тела функции (void)unused_variable; - вполне достаточно, чтобы предупреждения исчезли. Если в дальнейшем в функции переменная unused_variable всё-таки понадобится - это просто убирается.
[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3711955#p3711955"]То есть, тут и близко не пахнет перегрузкой. Это разные функции выполняющие разные действия при возникновении подобных событий. В данном случае - нажатии разных кнопок на одном и том же пульте ДУ на ИК лучах.[/uquote]
...и даже при всём при этом никто не мешает использовать для них операцию приведения типа чтобы положить все указатели в один массив.
Не понимаю - в чём проблема?
