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

ARV · Сообщение **ARV** » Чт окт 03, 2019 05:37:37

имхо: избавляться от варнингов нет необходимости, если они на самом деле являются следствием реализации алгоритма. варнинг говорит о том, что мнение компилятора и программиста по данному вопросу МОГУТ расходиться, но не факт, что это представляет проблему. приведение типа в данном случае является страусиной политикой: не вижу, значит, это не существует. а это заведомо хуже, чем вижу, но не боюсь, ибо...

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

для полностью "прозрачной" реализации я бы сделал как-то так:

Код: Выделить всё

typedef enum{
   DIR_FIRST,
// добавлять ниже, но не выше!
   DIR_NORD,
   DIR_EAST,
   DIR_SOUTH,
   DIR_WEST,
// ниже не добавлять!
   DIR_LAST
} direction_t;

direction_t rotate_right(direction_t current_dir){
   if(++current_dir >= DIR_LAST) current_dir = DIR_FIRST + 1;
   return current_dir;
}

direction_t rotate_left(direction_t current_dir){
   if(--current_dir == DIR_FIRST) current_dir = DIR_LAST - 1;
   return current_dir;

Реклама

jcxz

[uquote="ARV",url="/forum/viewtopic.php?p=3711791#p3711791"]имхо: избавляться от варнингов нет необходимости, если они на самом деле являются следствием реализации алгоритма. варнинг говорит о том, что мнение компилятора и программиста по данному вопросу МОГУТ расходиться, но не факт, что это представляет проблему. приведение типа в данном случае является страусиной политикой: не вижу, значит, это не существует. а это заведомо хуже, чем вижу, но не боюсь, ибо...[/uquote]
В корне неправильно!
От варнингов нужно избавляться всегда. Если Ваше мнение расходится с мнением компилятора хуже будет только вам. Потому что компилятор сделает по-своему. Он вас предупредил, Вы проигнорили - дальше виноваты сами за последствия.
Если на вас едет паровоз, машинист видит вас и предупреждает гудком чтобы Вы ушли с рельс. Если вы это проигнорите - паровозу от этого не поплохеет. Ну разве что скотоотбойник запачкает

А как именно избавляться - это уже можно делать по-разному.

Реклама

ПростоНуб

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

Код: Выделить всё

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"
...
#pragma GCC diagnostic pop

2. Усложняем алгоритм, разбивая таблицу на две и выполняя поиск нужного обработчика в обоих таблицах.

Пример:

Код: Выделить всё

typedef struct ir_cmd_st {
  uint8_t   code;
  uint8_t (*ir_handler)(uint8_t);
} ir_cmd_t;

static ir_cmd_t ir_cmd_table[] = {
  { IR_NEC_CMD_UP,    ir_handler_brightness },
  { IR_NEC_CMD_DOWN,  ir_handler_brightness },
  { IR_NEC_CMD_LEFT,  ir_handler_pgm_prev},
  { IR_NEC_CMD_RIGHT, ir_handler_pgm_next},
  { IR_NEC_CMD_OK,    ir_handler_switch_channel},
  { IR_NEC_CMD_0,     ir_handler_pgm_no},
  { IR_NEC_CMD_1,     ir_handler_pgm_no},
  { IR_NEC_CMD_2,     ir_handler_pgm_no},
  { IR_NEC_CMD_3,     ir_handler_pgm_no},
  { IR_NEC_CMD_4,     ir_handler_pgm_no},
  { IR_NEC_CMD_5,     ir_handler_pgm_no},
  { IR_NEC_CMD_6,     ir_handler_pgm_no},
  { IR_NEC_CMD_7,     ir_handler_pgm_no},
  { IR_NEC_CMD_8,     ir_handler_pgm_no},
  { IR_NEC_CMD_9,     ir_handler_pgm_no} };

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

GARMIN

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

Реклама

ПростоНуб

GARMIN, например, на SDCС и STM8S, для которого был использован данный код, Ваш подход приведет к дополнительным машинным командам в каждом обработчике, которому нужен код клавиши. Тогда как в моем случае, код клавиши сразу оказывается в аккумуляторе, где он и был в вызывающей программе при поиске обработчика в таблице. Мне даже в память этот код не нужно сохранять.

К тому же, это простейший пример. А бывают таблицы куда более сложных обработчиков. При этом, если у меня выбор между лишней pragma и потреблением дополнительной памяти в статическом сегменте SRAM, я выберу первое )

Реклама

VladislavS

ПростоНуб, вызываешь с параметром функцию без параметров? И эти люди запрещают мне перегрузку

Реклама

Eddy_Em

Убрал.
Нарушение Правил форума п. 2.3
aen

ПростоНуб

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

VladislavS

Я не про перегрузку спрашивал, а про вызов функции которая не принимает параметр вызовом с параметром. Это вообще нормально?

ПростоНуб

VladislavS, что значит "не принимает"? Я не понимаю Вашей терминологии.
Я вел речь только о тех случаях, когда один или несколько параметров функции не используются ей именно в целях унификации вызова в машинных кодах, увеличивая производительность кода и уменьшая его размер. Тогда как перегрузка в подобных случаях приводит к обратному - к увеличению размера кода и понижению быстродействия, так как компилятор уже не может развернуть такой код в таблицу вызовов функций.

VladislavS

То есть, все обработчики имеют одинаковый интетфейс? Тогда ладною. А то по тексту читалось что часть из них принимеют void, а часть принимают что-то.

Eddy_Em

ПростоНуб, можно и разное количество аргументов делать, но для этого придется с va_args заморачиваться, что жрет ресурсы... Проще уж написать __attribute__((unused)) на неиспользуемые функциями аргументы.

ПростоНуб

Eddy_Em, можно, но далеко не во всех компиляторах. Например, в SDCC только так:

Код: Выделить всё

#pragma save
#pragma disable_warning 85
...
#pragma restore

А данную конструкцию препроцессором намного проще сделать переносимой под разные компиляторы, чем __attribute__()

Eddy_Em

SDCC - вообще жутчайший компилятор! Оптимизацией там вообще не пахнет, иной раз как глянешь листинг - жесть! Приходится местами вручную оптимизировать (а то и ассемблерные вставки делать).
Но, к сожалению, порта gcc для STM8 нет, и приходится кривым sdcc собирать (больше-то компиляторов и нет под этот МК).

ПростоНуб

Eddy_Em, и не только для STM8. Для ряда МК он или единственный, или лучший вариант.
На самом деле, начиная с 3.8 оптимизацией там запахло. Даже 3.7 после 3.6 показалась манной небесной )
По крайней мере, уже начиная с 3.7 особого смысла использовать вместо SDCC COSMIC или IAR не стало.

Apparatchik

Подскажите пожалуйста: если локальную переменную объявить как static то ее значение сохраняется при выходе из функции. Но что будет если эту функцию вызывать рекурсивно? Будет выделятся память по мере вызовов и сохранятся? Интересует на языке Си.

VladislavS

По идее, будет одна переменная для всех рекурсий.

Apparatchik

Значит можно не боятся переполнения стека этими переменными.

VladislavS

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

ПростоНуб

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