Я часто слышу, что при компиляции программ на C и C++ я должен "всегда включать предупреждения компилятора". Почему это необходимо? Как мне это сделать?
Иногда я также слышу, что я должен "воспринимать предупреждения как ошибки". Нужно ли мне? Как мне это сделать?
Компиляторы C и C++, как известно, плохо по умолчанию сообщают о некоторых распространенных ошибках программиста, таких как:
return значение из функцииprintf и scanf не соответствуют строке форматаИх можно обнаружить и сообщить, но обычно это не по умолчанию; эта функция должна быть явно запрошена через параметры компилятора.
Это зависит от вашего компилятора.
Компиляторы Microsoft C и C++ понимают такие переключатели, как /W1, /W2, /W3, /W4 и /Wall. Используйте хотя бы /W3. /W4 и /Wall могут выдавать ложные предупреждения для системных заголовочных файлов, но если ваш проект корректно компилируется с одним из этих параметров, сделайте это. Эти параметры являются взаимоисключающими.
Большинство других компиляторов понимают такие опции, как -Wall, -Wpedantic и -Wextra. -Wall необходим, и все остальные рекомендуются (обратите внимание, что, несмотря на его название, -Wall включает только самые важные предупреждения, но не все). Эти параметры можно использовать отдельно или все вместе.
Ваша IDE может иметь возможность включить их из пользовательского интерфейса.
Предупреждение компилятора сигнализирует о потенциально серьезной проблеме в вашем коде. Проблемы, перечисленные выше, почти всегда являются фатальными; другие могут или не могут быть, но вы хотите, чтобы компиляция не удалась, даже если это ложная тревога. Изучите каждое предупреждение, найдите причину и устраните ее. В случае ложной тревоги обойдите ее, то есть используйте другую языковую функцию или конструкцию, чтобы предупреждение больше не срабатывало. Если это окажется очень сложно, отключите это конкретное предупреждение в каждом конкретном случае.
Вы не хотите просто оставлять предупреждения как предупреждения, даже если все они ложные тревоги. Это может быть хорошо для очень маленьких проектов, где общее количество отправленных предупреждений меньше 7. Все больше, и новое предупреждение легко потеряться в потоке старых знакомых. Не позволяй этого. Просто сделайте так, чтобы весь ваш проект компилировался чисто.
Обратите внимание, что это относится к разработке программ. Если вы публикуете свой проект для всего мира в исходной форме, то было бы неплохо не указывать -Werror или эквивалент в вашем выпущенном скрипте сборки. Люди могут попытаться построить ваш проект с другой версией компилятора или с другим компилятором, у которого может быть включен другой набор предупреждений. Вы можете хотеть, чтобы их сборка была успешной. Рекомендуется оставлять предупреждения включенными, чтобы люди, которые видят предупреждающие сообщения, могли отправлять вам сообщения об ошибках или исправления.
Это снова сделано с переключателями компилятора. /WX предназначен для Microsoft, большинство других используют -Werror. В любом случае компиляция не удастся, если появятся какие-либо предупреждения.
C, как известно, является языком довольно низкого уровня, как и HLL. C++, хотя это может показаться языком значительно более высокого уровня, чем C, все же разделяет ряд своих черт. И одна из этих черт заключается в том, что языки были разработаны программистами для программистов - и, в частности, программистов, которые знали, что они делают.
[В оставшейся части этого ответа я сосредоточусь на C. Большая часть того, что я скажу, также относится к C++, хотя, возможно, не так сильно. Хотя, как сказал Бьярн Страуструп, "С позволяет легко выстрелить себе в ногу; C++ делает его тяжелее, но когда вы делаете это, вырываете ногу целиком".]
Если вы знаете, что делаете - действительно знаете, что делаете - иногда вам, возможно, придется "нарушать правила". Но в большинстве случаев большинство из нас согласятся с тем, что из благих намерений правила избавляют нас от неприятностей, и что бессмысленное постоянное нарушение этих правил - плохая идея.
Но в C и C++ есть удивительно большое количество вещей, которые вы можете сделать, которые являются "плохими идеями", но формально не "противоречат правилам". Иногда они плохие идеи иногда (но могут быть оправданы в других случаях); иногда они плохая идея практически все время. Но традиция всегда состояла в том, чтобы не предупреждать об этих вещах - потому что, опять же, предполагается, что программисты знают, что они делают, они не будут делать эти вещи без веской причины, их будет раздражать куча ненужных предупреждений.
Но, конечно, не все программисты действительно знают, что делают. И, в частности, каждый программист C (независимо от его опыта) проходит этап становления программистом C. И даже опытные программисты на Си могут быть неосторожны и совершать ошибки.
Наконец, опыт показал, что программисты не только делают ошибки, но и могут иметь серьезные, серьезные последствия. Если вы допустили ошибку, и компилятор не предупредил вас об этом, и каким-то образом программа не сразу аварийно завершает работу или делает что-то явно неправильное из-за этого, ошибка может скрываться там, скрытая, иногда в течение многих лет, пока она не вызовет большая проблема.
Получается, что в большинстве случаев предупреждения - это хорошая идея. Даже опытные программисты узнали (на самом деле, это "особенно опытные программисты узнали"), что в целом предупреждения имеют тенденцию приносить больше пользы, чем вреда. Каждый раз, когда вы умышленно что-то делали неправильно, а предупреждение было неприятным, вероятно, вы, по крайней мере, десять раз делали что-то неправильно, и предупреждение спасало вас от дальнейших неприятностей. И большинство предупреждений можно отключить или обойти для тех немногих случаев, когда вы действительно хотите сделать "не то".
(Классическим примером такой "ошибки" является тест if(a = b). В большинстве случаев это ошибка, поэтому большинство компиляторов в наши дни предупреждают об этом - некоторые даже по умолчанию. Но если вы действительно хотите назначить оба От b до a и проверьте результат, вы можете отключить предупреждение, набрав if((a = b)).)
Второй вопрос: почему вы хотите попросить компилятор рассматривать предупреждения как ошибки? Я бы сказал это из-за человеческой природы, в частности, из-за слишком простой реакции: "О, это просто предупреждение, это не так важно, я уберу это позже". Но если вы прокрастинатор (и я не знаю о вас, но я ужасный прокрастинатор), то легко отменить обязательную очистку практически навсегда - и если вы привыкли игнорировать предупреждения, это становится все легче пропустить важное предупреждающее сообщение, которое остается незамеченным среди всех тех, кого вы игнорируете.
Поэтому попросить компилятор рассматривать предупреждения как ошибки - это небольшая хитрость, которую вы можете сыграть на себе, чтобы обойти эту человеческую слабость.
Лично я не так настойчиво отношусь к обработке предупреждений, как к ошибкам. (На самом деле, если честно, я могу сказать, что я практически никогда не включаю эти опции в моем "личном" программировании.) Но вы можете быть уверены, что я включил эту опцию на работе, где наше руководство по стилю (которое я писал) обязывает его использовать. И я бы сказал - я подозреваю, что большинство профессиональных программистов скажут - что любой магазин, который не рассматривает предупреждения как ошибки в С, ведет себя безответственно, не придерживается общепринятых лучших отраслевых практик.
Предупреждения состоят из лучших советов, которые некоторые из наиболее опытных разработчиков C++ могут испечь в приложении. Их стоит держать рядом.
C++, будучи полным языком Тьюринга, имеет множество случаев, когда компилятор должен просто поверить, что вы знали, что делаете. Однако во многих случаях компилятор может понять, что вы, вероятно, не намеревались писать то, что написали. Классическим примером являются коды printf(), которые не соответствуют аргументам, или std::strings, переданные в printf (не то, что когда-либо случалось со мной!). В этих случаях написанный вами код не является ошибкой. Это допустимое выражение C++ с допустимой интерпретацией для компилятора. Но у компилятора есть сильное предчувствие, что вы просто пропустили что-то, что легко обнаружить современному компилятору. Это предупреждения. Это вещи, которые очевидны для компилятора, использующего все строгие правила C++ в его распоряжении, которые вы могли упустить из виду.
Отключать предупреждения или игнорировать их - все равно что игнорировать бесплатные советы от тех, кто более опытен, чем вы. Это урок huberis, который заканчивается, когда вы летите слишком близко к солнцу и ваши крылья тают, или возникает ошибка повреждения памяти. Между этими двумя я буду падать с неба каждый день!
"Рассматривать предупреждения как ошибки" - крайняя версия этой философии. Идея заключается в том, что вы разрешаете каждое предупреждение, которое дает вам компилятор - вы слушаете каждый бесплатный совет и действуете на нем. Является ли это хорошей моделью для развития, зависит от команды и от того, над каким продуктом вы работаете. Это аскетический подход, который мог бы иметь монах. Для некоторых это прекрасно работает. Для других это не так.
Во многих моих приложениях мы не рассматриваем предупреждения как ошибки. Мы делаем это, потому что эти конкретные приложения должны компилироваться на нескольких платформах с несколькими компиляторами разного возраста. Иногда мы обнаруживаем, что на самом деле невозможно зафиксировать предупреждение на одной стороне, не превратив его в предупреждение на другой платформе. Так что мы просто осторожны. Мы уважаем предупреждения, но не загибаемся за них.
Обработка предупреждений не только улучшает код, но и делает программиста лучше. Предупреждения расскажут вам о вещах, которые сегодня могут показаться вам незначительными, но однажды эта дурная привычка вернется и оpipeит вам голову.
Используйте правильный тип, верните это значение, оцените это возвращаемое значение. Потратьте время и подумайте: "Действительно ли это правильный тип в этом контексте?" "Мне нужно вернуть это?" И важная персона; "Будет ли этот код переносимым в течение следующих 10 лет?"
Привыкайте писать код без предупреждения.
Другие ответы превосходны, и я не хочу повторять то, что они сказали.
Еще один аспект "зачем включать предупреждения", который не был должным образом затронут, заключается в том, что они чрезвычайно помогают в обслуживании кода. Когда вы пишете программу значительного размера, становится невозможным держать все это в голове сразу. Обычно у вас есть функция или три, о которых вы активно пишете и думаете, и, возможно, файл или три на вашем экране, к которым вы можете обратиться, но основная часть программы находится где-то в фоновом режиме, и вы должны верить, что она продолжает работать.
Наличие предупреждений и наличие их как можно более энергичных и на вашем лице помогает предупредить вас, если что-то, что вы меняете, создает проблемы для чего-то, что вы не можете видеть.
Взять, к примеру, предупреждение о лязге -Wswitch-enum. Это вызывает предупреждение, если вы используете переключатель enum и пропускаете одно из возможных значений enum. Это то, что вы могли бы подумать, было бы маловероятной ошибкой: вы, по крайней мере, смотрели на список значений enum, когда писали оператор switch. У вас может даже быть IDE, которая генерирует параметры переключения для вас, не оставляя места для человеческой ошибки.
Это предупреждение действительно вступает в силу, когда через шесть месяцев вы добавляете еще одну возможную запись в перечисление. Опять же, если вы думаете о рассматриваемом коде, вы, вероятно, будете в порядке. Но если это перечисление используется для нескольких различных целей и для одной из тех, в которой вам нужна дополнительная опция, очень легко забыть обновить переключатель в файле, к которому вы не обращались в течение 6 месяцев.
Вы можете думать о предупреждениях так же, как и об автоматизированных тестовых примерах: они помогают вам убедиться в том, что код имеет смысл, и делают то, что вам нужно, когда вы впервые пишете его, но они еще больше помогают убедиться, что он продолжает делать то, что вам нужно, пока вы подталкиваете к этому. Разница в том, что контрольные примеры работают очень близко к требованиям вашего кода, и вы должны их писать, в то время как предупреждения работают в широком смысле в соответствии с разумными стандартами почти для всего кода, и они очень щедро поставляются блоками, которые создают компиляторы.
Например, для отладки ошибки сегментации программист должен проследить корень (причину) ошибки, которая обычно находится в вашем коде раньше, чем строка, которая в конечном итоге вызвала ошибку сегментации.
Очень типично, что причиной является строка, для которой компилятор выдал предупреждение, которое вы проигнорировали, и строка, которая вызвала ошибку сегментации, строка, которая в конечном итоге вызвала ошибку.
Исправление предупреждения приводит к решению проблемы. Классика!
Демонстрация вышесказанного. Рассмотрим следующий код:
#include <stdio.h>
int main(void) {
char* str = "Hello world!";
int idx;
// Colossal amount of code here, irrelevant to 'idx'
printf("%c\n", str[idx]);
return 0;
}
который при компиляции с флагом "Wextra" передается в GCC, дает:
main.c: In function 'main':
main.c:9:21: warning: 'idx' is used uninitialized in this function [-Wuninitialized]
9 | printf("%c\n", str[idx]);
| ^
который я мог бы игнорировать и выполнить код в любом случае... А потом я стал бы свидетелем "грандиозной" ошибки сегментации, как говаривал мой профессор по эпикуру IP:
Ошибка сегментации
Чтобы отладить это в сценарии реального мира, нужно начать со строки, вызывающей ошибку сегментации, и попытаться выяснить, в чем причина. Они должны будут искать то, что случилось с i и str внутри этого колоссального количества кода там...
До тех пор, пока однажды они не оказались в ситуации, когда обнаружил, что i используется неинициализированным, таким образом, он имеет значение мусора, что приводит к индексации строки (пути) за ее пределами, что приводит к ошибке сегментации.
Если бы только они не проигнорировали предупреждение, они бы сразу нашли ошибку!
Рассматривать предупреждения как ошибки - это просто средство самодисциплины: вы составляли программу для тестирования этой новой блестящей функции, но вы не можете, пока не исправите неаккуратные части. Werror не предоставляет никакой дополнительной информации, он просто очень четко устанавливает приоритеты:
Не добавляйте новый код, пока не исправите проблемы в существующем коде
Это действительно образ мышления, который важен, а не инструменты. Вывод диагностики компилятора является инструментом. MISRA (для встроенного C) - еще один инструмент. Неважно, какой из них вы используете, но, возможно, предупреждения компилятора - это самый простой инструмент, который вы можете получить (его нужно установить только одним флагом), а отношение сигнал/шум очень высокое. Так что нет никаких причин не использовать его.
Ни один инструмент не является непогрешимым. Если вы напишите const float pi = 3.14;, большинство инструментов не скажут вам, что вы определили π с плохой точностью, что может привести к проблемам в будущем. Большинство инструментов не поднимут брови на if(tmp < 42), даже если общеизвестно, что присвоение переменных бессмысленным именам и использование магических чисел - это путь к катастрофе в больших проектах. Вы должны понимать, что любой код "быстрого тестирования", который вы пишете, - это просто тест, и вы должны получить его прямо перед тем, как переходить к другим задачам, пока вы все еще видите его недостатки. Если вы оставите эти коды как есть, отладка, если по истечении двух месяцев добавление новых функций будет значительно сложнее.
Как только вы попадаете в правильное мышление, нет смысла использовать Werror. Наличие предупреждений в качестве предупреждений позволит вам принять информированное решение о том, имеет ли смысл запускать тот сеанс отладки, который вы собирались запустить, или прервать его и сначала исправить предупреждения.
Как человек, работающий с унаследованным встроенным кодом C, включение предупреждений компилятора помогло показать много слабых мест и областей, которые необходимо исследовать при предложении исправлений. В gcc использование -Wall и -Wextra и даже -Wshadow стали жизненно важными. Я не буду вдаваться в каждую опасность, но перечислю несколько всплывающих, которые помогли показать проблемы с кодом.
Это может легко указать на незаконченную работу и области, которые могут не использовать все переданные переменные, которые могут быть проблемой. Давайте посмотрим на простую функцию, которая может вызвать это:
int foo(int a, int b)
{
int c = 0;
if (a > 0)
{
return a;
}
return 0;
}
Простая компиляция без -Wall или -Wextra не возвращает никаких проблем. -Wall скажет вам, что c никогда не используется:
foo.c: In function ‘foo:
foo.c:9:20: warning: unused variable ‘c [-Wunused-variable]
-Wextra также скажет вам, что ваш параметр b ничего не делает:
foo.c: In function ‘foo:
foo.c:9:20: warning: unused variable ‘c [-Wunused-variable]
foo.c:7:20: warning: unused parameter ‘b [-Wunused-parameter] int foo(int a, int b)
Это немного сложно и не показывалось, пока не был использован -Wshadow. Давайте изменим приведенный выше пример, добавив его, но в нем есть глобал с тем же именем, что и локальный, что вызывает путаницу при попытке использовать оба варианта.
int c = 7;
int foo(int a, int b)
{
int c = a + b;
return c;
}
Когда -Wshadow был включен, эту проблему легко обнаружить.
foo.c: 11: 9: предупреждение: объявление ‘c затеняет глобальное объявление [-Wshadow]
foo.c: 1: 5: note: теневое объявление здесь
Это не требует каких-либо дополнительных флагов в gcc, но все еще является источником проблем в прошлом. Простая функция, пытающаяся напечатать данные, но с ошибкой форматирования, может выглядеть так:
void foo(const char * str)
{
printf("str = %d\n", str);
}
Это не печатает строку, так как флаг форматирования неверен, и gcc с радостью скажет вам, что это, вероятно, не то, что вы хотели:
foo.c: In function ‘foo:
foo.c: 10: 12: предупреждение: формат ‘% d ожидает аргумент типа ‘int, но аргумент 2 имеет тип‘ const char * [-Wformat =]
Это всего лишь три из множества вещей, которые компилятор может перепроверить для вас. Есть много других, таких как использование неинициализированной переменной, на которую указывали другие.
Это конкретный ответ для C, и почему это гораздо важнее для C, чем для чего-либо еще.
#include <stdio.h>
int main()
{
FILE *fp = "some string";
}
Этот код компилируется с предупреждением. То, что есть и должно быть ошибками практически во всех других языках на планете (за исключением языка ассемблера), является предупреждением на C. Предупреждения на C почти всегда являются замаскированными ошибками. Предупреждения должны быть исправлены, а не подавлены.
С gcc мы делаем это как gcc -Wall -Werror.
Это также послужило причиной высокой вероятности некоторых предупреждений небезопасных API MS. Большинство людей, программирующих на C, научились жестко относиться к предупреждениям как к ошибкам, и казалось, что это не совсем то же самое, и им нужны непереносимые исправления.
Предупреждения компилятора в C++ очень полезны по некоторым причинам.
1 - Это позволяет показать вам, где вы могли совершить ошибку, которая может повлиять на конечный результат вашей работы. Например, если вы не инициализировали переменную или вы поставили "=" вместо "==" (есть только примеры)
2 - Позволяет также показать вам, где ваш код не соответствует стандарту C++. Это полезно, потому что, если код соответствует действующему стандарту, будет легко переместить код, например, в другую табличную форму.
В общем, предупреждения очень полезны, чтобы показать вам, где у вас есть ошибки в вашем коде, которые могут повлиять на результат вашего алгоритма или предотвратить некоторые ошибки, когда пользователь будет использовать вашу программу.
Вы должны всегда включать предупреждения компилятора, потому что компилятор часто может сказать вам, что не так с вашим кодом. Для этого вы передаете -Wall -Wextra компилятору.
Обычно вы должны рассматривать предупреждения как ошибки, потому что часто предупреждения обычно указывают на то, что с вашим кодом что-то не так. Однако часто очень легко игнорировать эти ошибки. Поэтому обработка их как ошибок приведет к сбою сборки, поэтому вы не сможете игнорировать ошибки. Чтобы воспринимать предупреждения как ошибки, передайте -Werror компилятору.
Предупреждение - ошибка, ожидающая, чтобы случиться. Таким образом, вы должны включить предупреждения компилятора и привести в порядок свой код, чтобы удалить любое предупреждение.
Существует только одна проблема с обработкой предупреждений как с ошибками: когда вы используете код, поступающий из других источников (например, из микро $ ** t-библиотек, проектов с открытым исходным кодом), они не справляются со своей задачей, и компиляция их кода генерирует тонны предупреждений.
Я всегда пишу свой код, чтобы он не генерировал никаких предупреждений или ошибок, и очищаю его до тех пор, пока он не скомпилируется, не создавая посторонних шумов. Мусор, с которым мне приходится работать, ужасает меня, и я поражен, когда мне приходится создавать большой проект и наблюдать за потоком предупреждений, когда компиляция должна только сообщать, какие файлы она обработала.
Я также документирую свой код, потому что я знаю, что реальные затраты на программное обеспечение в течение всей жизни в основном связаны с его обслуживанием, а не с первоначальной записью, а с другой историей...
Однажды я работал в крупной (Fortune 50) компании, которая производила электронное испытательное оборудование.
Основным продуктом моей группы была программа MFC, которая на протяжении многих лет генерировала буквально сотни предупреждений. Которые были проигнорированы почти во всех случаях.
Это ужасный кошмар, когда появляются ошибки.
После этой должности мне посчастливилось быть первым разработчиком в новом стартапе.
Я рекомендовал политику "без предупреждения" для всех сборок, когда уровни предупреждений компилятора были довольно шумными.
Наша практика заключалась в том, чтобы использовать предупреждение #pragma - push/disable/pop для кода, который, как был уверен разработчик, действительно был в порядке, наряду с оператором log на уровне отладки, на всякий случай.
Эта практика хорошо сработала для нас.
Некоторое предупреждение может означать возможную семантическую ошибку в коде или возможный UB. Например. ; после if(), неиспользуемая переменная, глобальная переменная, маскируемая локальным, или сравнение подписанного и неподписанного. Многие предупреждения связаны со статическим анализатором кода в компиляторе или с нарушениями стандарта ISO, обнаруживаемыми во время компиляции, которые "требуют диагностики". Хотя эти случаи могут быть законными в одном конкретном случае, в большинстве случаев они будут результатом проблем с дизайном.
Некоторые компиляторы, например GCC, есть опция командной строки, чтобы активировать режим "предупреждения как ошибки", это хороший, хотя и жестокий инструмент для обучения начинающих программистов.
Игнорирование предупреждений означает, что вы оставили неаккуратный код, который не только может вызвать проблемы у кого-то в будущем, но и сделает важные сообщения компиляции менее заметными для вас. Чем больше выходных данных компилятора, тем меньше кто-нибудь заметит или побеспокоит. Чем чище, тем лучше. Это также означает, что вы знаете, что делаете. Предупреждения очень непрофессиональны, небрежны и рискованны.
ПРЕДУПРЕЖДЕНИЯ О КОМПИЛЕРЕ - ВАШ ДРУГ (не кричите, заглавные буквы).
Я работаю на старых системах Fortran-77. Компилятор говорит мне ценные вещи: несоответствие типа данных аргумента при вызове подпрограммы, использование локальной переменной до того, как значение было установлено в переменную, если у меня есть переменная или аргумент подпрограммы, которые не используются. Это почти всегда ошибки.
Избегайте длинных постов: Когда мой код компилируется чисто, 97% это работает. Другой парень, с которым я работаю, компилирует все предупреждения, проводит часы или дни в отладчике, а затем просит меня помочь. Я просто скомпилировал его код с предупреждениями и сказал ему, что нужно исправить.
Тот факт, что компиляторы C++ принимают код компиляции, который, очевидно, приводит к неопределенному поведению, является основным недостатком компиляторов. Причина, по которой они не исправляют это, заключается в том, что это может привести к поломке некоторых полезных сборок.
Большинство предупреждений должны быть фатальными ошибками, которые мешают завершению сборки. По умолчанию просто отображать ошибки и выполнять сборку в любом случае неправильно, и если вы не переопределите их для обработки предупреждений как ошибок и оставите некоторые предупреждения, то вы, скорее всего, закончите с аварийным завершением вашей программы и выполнением случайных действий.
Вы должны обязательно включить предупреждения компилятора, так как некоторые компиляторы плохо сообщают о некоторых распространенных ошибках программирования, включая следующие: -
-> инициализация переменной забывается -> вернуть значение из функции пропущено -> простые аргументы в семействах printf и scanf, не соответствующие строке формата функция используется без предварительного объявления, хотя это происходит только в c
Так как эти функции могут быть обнаружены и сообщены, просто обычно не по умолчанию; поэтому эту функцию необходимо явно запрашивать с помощью параметров компилятора.
Ведущий ученый NASA Джерард Дж. Хольцманн разработал правила кодирования на 10 C, которые могут быть применены и к другим языкам программирования. Одно правило касается предупреждений:https://www.rankred.com/nasa-coding-rules/
Полегче: вам не нужно, это не нужно. -Wall и -Werror были разработаны маньяками рефакторинга кода для себя: это было изобретено разработчиками компилятора, чтобы избежать разрушения существующих сборок после обновления компилятора на стороне пользователя. Эта особенность - не что иное, как решение о нарушении или отказе от сборки.
Это полностью зависит от вашего предпочтения, использовать его или нет. Я использую это все время, потому что это помогает мне исправить мои ошибки.