Лучший уровень предупреждения компилятора для компиляторов C/С++?

Ответ 1

Это набор лишних параноидных флагов, которые я использую для кода С++:

    -g -O -Wall -Weffc++ -pedantic  \
    -pedantic-errors -Wextra -Waggregate-return -Wcast-align \
    -Wcast-qual  -Wchar-subscripts  -Wcomment -Wconversion \
    -Wdisabled-optimization \
    -Werror -Wfloat-equal  -Wformat  -Wformat=2 \
    -Wformat-nonliteral -Wformat-security  \
    -Wformat-y2k \
    -Wimplicit  -Wimport  -Winit-self  -Winline \
    -Winvalid-pch   \
    -Wunsafe-loop-optimizations  -Wlong-long -Wmissing-braces \
    -Wmissing-field-initializers -Wmissing-format-attribute   \
    -Wmissing-include-dirs -Wmissing-noreturn \
    -Wpacked  -Wpadded -Wparentheses  -Wpointer-arith \
    -Wredundant-decls -Wreturn-type \
    -Wsequence-point  -Wshadow -Wsign-compare  -Wstack-protector \
    -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch  -Wswitch-default \
    -Wswitch-enum -Wtrigraphs  -Wuninitialized \
    -Wunknown-pragmas  -Wunreachable-code -Wunused \
    -Wunused-function  -Wunused-label  -Wunused-parameter \
    -Wunused-value  -Wunused-variable  -Wvariadic-macros \
    -Wvolatile-register-var  -Wwrite-strings

Это должно дать вам кое-что для начала. В зависимости от проекта вам может потребоваться его тон, чтобы не видеть предупреждения, поступающие от сторонних библиотек (которые, как правило, довольно неосторожны относительно бесплатного предупреждения). Например, векторный/матричный код Boost заставит g++ испускать много шума.

Лучший способ справиться с такими случаями - написать оболочку вокруг g++, которая по-прежнему использует предупреждения, настроенные до max, но позволяет подавлять их от просмотра определенных файлов/номеров строк. Я написал такой инструмент давно и выпустил его, как только у меня есть время его очистить.

Ответ 2

В Visual С++ я использую /W4 и /WX (рассматриваю предупреждения как ошибки).

VC также имеет /Wall, но он несовместим со стандартными заголовками.

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

Ответ 3

Я считаю, что VC также поддерживает

#pragma message ("note to self")

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

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

Вот почему я пытаюсь обрабатывать предупреждения как ошибки: большую часть времени компилятор правильно предупреждает меня, а если нет, я документирую его в коде и добавляю

#pragma warning ( push )
#pragma warning ( 4191 : disable )
// violent code, properly documented
#pragma warning ( pop )

I просто прочитал, у них также есть прагма warning ( N : suppress ).

Ответ 4

Я обычно использую -Wall (потому что все делают ошибки, никто не идеален), но я не использую -Werror (рассматриваю предупреждения как ошибки), потому что время от времени gcc предупреждает о вещах, которые являются правильными в любом случае ( ложные срабатывания).

Ответ 5

Я согласен с litb, чтобы всегда использовать -Wall. Кроме того, если вы хотите, чтобы ваш код был совместим, вы также можете использовать -pedantic. Еще одно предупреждение, которое может быть полезно, если вы обрабатываете союзы и структуры на байтовом уровне, - Wpadded.

Ответ 6

Я делаю все разработки с предупреждением при включении ошибок.

Так как я все еще развивается в VC6, у меня много # прагмы в моем коде (4786 в основном).

Ответ 7

Мне нравятся -Wall и строгие прототипы, а также неявные определения функций. Ошибки на них могут быть очень полезными. Там также -Wextra, который будет захватывать все виды вещей, как вещи, которые вы намеревались быть условными, но случайно написал как утверждения:

if (something);
   classic_way_to_leak_memory();

В Unix-подобных системах вы должны подчиняться предпочтениям пользователя ENV.. поэтому то, что они видят и сообщают, может быть совершенно иным, чем то, что вам нужно:)

Я тоже типа punning fiend, поэтому я предпочитаю устанавливать -Fno-strict-aliasing, если только пользователь этого не хочет. Безопасное управление памятью в классическом C трудно выполнить иначе.

Ответ 8

Здесь есть хороший список вариантов для GCC: http://mces.blogspot.com/2008/12/year-end-cleaning-ie-on-warning-options.htm. -Wall не включает все возможные предупреждения, а некоторые из них должны быть включены явно.

Ответ 9

В Visual C я использую /w 3. Я нахожу, что w4 вызывает слишком много шума (много из библиотек MS), чтобы пройти через каждую сборку. Дополнительные предупреждения очень незначительны и до сих пор не были причиной ошибки.

Ответ 10

В GCC для предпочтения я использую "-Wall -Wextra -Wwrite-strings -Werror", а также задает стандарт со std =. Какой стандарт зависит от проекта: в основном от того, насколько портативным оно должно быть.

Причина, по которой я использую -Werror, заключается в том, что предупреждения неприемлемы (для меня), даже если они не представляют собой реальную ошибку. Я предпочел бы обойти все, что вызвало предупреждение, чем игнорировать предупреждения каждый раз, когда я собираюсь всю оставшуюся жизнь. Как только вы разрешите предупреждения в компиляции, просто слишком легко пропустить тот, который не был в последний раз.

Конечно, имея дело с сторонним кодом, иногда вы не можете избавиться от предупреждений. Затем я решил в каждом конкретном случае решить, следует ли ослабить опции -W, удалить -Werror и написать script, чтобы проверить, что только ожидают предупреждения, или, возможно, изменить сторонний код (либо на "исправить" предупреждение или отключить его с помощью прагм, если это возможно).

Ответ 11

никто еще не упомянул компилятор Intel:

https://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-D060680A-1A18-4574-8291-5C74E6E31335.htm

-w3 довольно болтливый, поэтому я предлагаю -w2

Ответ 12

Мне также нравится проверять все возможные предупреждения, которые дают компилятор в моем проекте. К сожалению, ответ о компиляторе Intel С++ был для меня не очень информативным (ссылка мертва). Я провел собственное исследование.

Поскольку я использую Qt 5 и qmake, у меня есть предопределенный уровень предупреждения -w1. Не могу с этим ничего не делать. Но это еще не все, и ICC имеет больше ключей:

-Wcomment 
-Weffc++ 
-Wextra-tokens 
-Wformat 
-Winline // don't use, show only for example
-Wmain 
-Wmissing-declarations 
-Wmissing-prototypes 
-Wnon-virtual-dtor 
-Wp64 
-Wpointer-arith 
-Wremarks 
-Wreturn-type 
-Wsign-compare 
-Wstrict-aliasing 
-Wstrict-prototypes 
-Wtrigraphs 
-Wuninitialized 
-Wunknown-pragmas 
-Wunused-variable

Подробнее о клавишах.

Также я хочу добавить, что, в отличие от GCC, ICC создает несколько предупреждений для одного ключа, например key -WeffС++. Если вы хотите увидеть только несколько предупреждений из всех списков, используйте клавишу -wd.

Я отключу: -wd1418,2012,2015,2017,2022,2013. И предупреждения -wd1572,873,2259,2261 по умолчанию отключены в qmake.

Я использую PCH и нашел очень раздражающим, чтобы видеть в сообщениях Qt Creator об использовании файла PCH, такого как ошибка. Чтобы отключить, используйте -Wno-pch-messages.

Для отключения предупреждения в коде я используйте:

#if defined(Q_CC_INTEL)
    #pragma warning( push )
    #pragma warning( disable: 2021 )
#endif

// some code

#if defined(Q_CC_INTEL)
    #pragma warning( pop )
#endif

Ответ 13

Спасибо всем за их ответы. Прошло некоторое время с тех пор, как я использовал что-либо, кроме gcc/g++. Я уже давно использовал

-fmessage-length = 0 (since g++ had an ugly habit of line breaking messages)

-Wno-deprecated      (since I worked on a code base pre-existing the std namespace)

Я помню, что (как минимум 5 лет назад) ничего выше уровня предупреждения по умолчанию в компиляторе Sun Workshop CC было слишком много. Я также думаю, что это могло быть правдой для компилятора Intel. Я не был в курсе компиляторов non gnu некоторое время.

Ответ 14

Компиляторы GCC становятся более строгими с каждой новой версией. Используйте флаг -ansi для получения предупреждений о нарушениях строжайшей интерпретации стандартов языка ANSI. Обычно это то, что просто происходит в вашем текущем компиляторе, но может приводить к ошибкам в следующей версии или в других компиляторах. Этот флаг поможет вам избежать необходимости переносить свой код каждый раз при переключении компиляторов/версий.