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

Question

Какой уровень предупреждения компилятора вы рекомендуете для разных компиляторов C / C ++?

gcc и g ++ позволят вам многое сделать на уровне по умолчанию. Я считаю, что лучший уровень предупреждения для меня - «Стена». И я всегда пытаюсь удалить код исправления для предупреждений, которые он генерирует. (Даже глупые об использовании скобок для правил логического приоритета или сказать, что я действительно имею в виду «если (х = у)»)

Какие ваши любимые уровни для разных компиляторов, таких как Sun CC, aCC (HPUX?), Visual Studio, intel?

Edit:

Я просто хотел отметить, что я не использую "-Werror" (но я понимаю, что это утилита) в gcc / g ++, потому что я использую:

#warning "this is a note to myself"

в нескольких местах в моем коде. Все ли компиляторы понимают макрос #warning?

Answer 1

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

    -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 ++, которая по-прежнему использует предупреждения, настроенные на максимум, но позволяющие подавить их просмотр для определенных файлов / номеров строк. Я написал такой инструмент давным-давно и выпущу его, как только у меня будет время его почистить.

Answer 2

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

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

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

Answer 3

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

#pragma message ("note to self")

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Поскольку я все еще развиваюсь в VC6, в моем коде много # прагм (в основном 4786).

Answer 7

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

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

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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

if (something);
   classic_way_to_leak_memory();

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

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