Опасные способы удаления предупреждений компилятора?

Question

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

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

Больше всего мне известно о явном приведении типов, которое может скрыть ошибку.

На какие еще потенциально опасные способы удаления предупреждений компилятора в C(++) мне следует обратить внимание?

Answer 1

Корректность const может вызвать несколько проблем у новичков:

// following should have been declared as f(const int & x)
void f( int & x ) {
  ...
}

позже:

// n is only used to pass the parameter "4"
int n = 4;
// really wanted to say f(4)
f( n );

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

Редактировать2: Еще один вариант, с которым я столкнулся (возможно, от Java-программистов), — это привязка спецификаций throw() к функциям, независимо от того, могут ли они на самом деле выбрасывать вызовы или нет.

Answer 2

Ну, есть очевидный способ — отключить конкретное предупреждение для частей кода:

#pragma warning( disable : 4507 34 )

РЕДАКТИРОВАТЬ:Как отмечалось в комментариях, иногда необходимо использовать в тех случаях, когда вы знаете, что с предупреждениями все в порядке (если бы это не была полезная функция, вообще не было бы смысла ее устанавливать) .Тем не менее, это также очень простой способ «игнорировать» предупреждения в вашем коде и при этом заставить его бесшумно компилироваться, о чем и был исходный вопрос.

Answer 3

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

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

Кроме того, разные версии компилятора будут выдавать разные предупреждения, поэтому становится более бессмысленным применять политику «отсутствия предупреждений», когда результат зависит от настроения разработчиков компилятора.

Я хочу подчеркнуть, насколько важно хотя бы один раз проверить все предупреждения.

Кстати, я разрабатываю на C и C++ для встраиваемых систем.

Answer 4

Комментирование (или, что еще хуже, удаление) кода, генерирующего предупреждение.Конечно, предупреждение исчезнет, ​​но вы, скорее всего, получите код, который не делает то, что вы намереваетесь.

Answer 5

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

То, что вы описали, не является проблемой, уникальной для предупреждений.Я не могу сказать вам, сколько раз я видел, как кто-то исправляет ошибку, приводящую к сбою, в виде «Я добавил пару NULL-проверок».Вам необходимо обратиться к первопричине:Должна ли эта переменная иметь значение NULL?Если нет, то почему?

Вот почему у нас есть обзоры кода.

Answer 6

Самый большой риск заключается в том, что кто-то потратит часы разработки на устранение незначительного предупреждения, не влияющего на код.Это было бы пустой тратой времени.Иногда проще сохранить предупреждение и добавить строку комментария, объясняющую, почему появляется предупреждение.(Пока кто-нибудь не успеет устранить эти тривиальные предупреждения.)

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