Это просто прекрасно. С одной стороны — предупреждения неспроста, с другой — необязательны. И кто-то еще должен раз и навсегда решить, какие из них важные, а какие нет.
Пост не о том, нужно ли давить предупреждения и можно ли давить предупреждения, он о том, как их давить после получения той самой визы у техлида.
DRY — отлично, но каждый раз как в коде встречается #include, код из заголовка копируется в текущую единицу трансляции. Кстати, в тексте поста об этом тоже говорится.
>-Wold-style-cast, от которого тоже никакого профита — кому, кроме pure C++-наци, какая разница, каким способом я скастую int в long, сишный способ просто короче;
Я не спорю, что падение может быть более жестким, чем предполагается. Я хотел сказать другое: не только такое жесткое падение является серьезной проблемой, более мягкие на первый взгляд проявления ошибок тоже могут быть серьезной проблемой. Вот скажем сервер выдает сообщение об ошибке на запрос определенного URL, а вы скажем этот URL разместили в качестве ссылки на скачивание вашего продукта — пользователи уже не смогут так легко скачать ваш продукт.
Сервер не обязан «совсем падать» — он может выдать сообщение об ошибке только тому, кто направил запрос. Более вероятный сценарий такой: вы переходите в браузере по длинной сложной ссылке с кучей параметров, а сервер вам возвращает сообщение об ошибке самого общего вида «что-то пошло не так, попробуйте открыть заглавную страницу», потому что именно эта длинная сложная ссылка приводит к ситуации вроде описанной выше. Никто не умер, нет, но в итоге «не работает» на ровном месте.
>Может просто вводить аттестацию на право использовать те или иные возможности языка и библиотек?
Сложно проверить, что человек действительно хорошо понимает, что делает. На вопросы он, скажем, все ответит, но это не гарантия хорошего понимания и способности правильно применить знания в сложной ситуации.
Кстати, о пилотах. В самолете есть так называемый авиагоризонт — устройство, показывающее наклон самолета. Он может быть реализован одним из двух способов. Либо профиль самолета изображается всегда горизонтальным, а реальный горизонт изображается наклоненным относительно него, либо наоборот — горизонт отображается неподвижным, а самолет изображается наклоненным. Очевидно, что один и тот же реальный наклон самолета в этих двух системах показывается противоположным образом. Не могу утверждать этого сам, но не раз слышал, что часть аварий происходит, когда пилот, летавший много лет на самолете с авиагоризонтом одного типа и переученный на самолет с авиагоризонтом другого типа при нештатной ситуации выполняет маневр, противоположный необходимому, и именно это приводит к аварии.
Это я к тому, что формальная аттестация очень далека от идеала.
Что значит «опасного»? Никто не умер, нет, и деньги не пропали. Но по сути программа сломалась на ровном месте. Вызывающий код хотел всего лишь вывести в отладчик «открываю файл такой-то» и тут — тыдыщь — недостаточно памяти.
>Можно вообще на каждую сточку в Си/Си++ программе ругаться. Так точно ничего не пропустишь.
Я знаю, что вы иронизируете, но сейчас вы озвучили распространенное заблуждение. Почему-то считается, что нужно выдавать как можно больше предупреждений, от этого анализ как будто становится полнее и полезнее. На самом деле, конечно, нужно выдавать как можно больше полезных предупреждений, иначе пользователь просто перестанет реагировать на шум и будет глушить предупреждения, «чтобы не мешали».
Обычно что-то становится «вне закона» после того, как оказывается, что слишком мало людей готово разбираться, как этим правильно пользоваться. Тогда вместо того, чтобы быть внимательнее, это объявляют вне закона и начинают неправильно пользоваться чем-то попроще.
С константной строкой не намного лучше. Например, в Visual C++ runtime есть _vsnwprintf_s() — недавно нашли случай, когда в нее в качестве строки форматирования подавалась строка с именем файла, содержащим многочисленные символы "%", функция просила под результат форматирования больше памяти, чем можно было выделить в программе (типа пару гигабайт), вызывающий код выдавал ошибку «недостаточно памяти».
Людям свойственно не быть все время предельно внимательными. Совершенно типичная ситуация, когда один разработчик с годами опыта пишет код, проверяет его, потом другой его открывает — и сразу находит пару нелепейших ошибок.
Если бы только вы могли знать, как вы заблуждаетесь. Такие ошибки допускают люди с многими годами опыта. В Visual C++ даже есть предупреждение C9430 на один из случаев такой ситуации.
Нет, это я неверно сформулировал мысль. Естественно, RAII есть в С++, но как только вы начинаете полноценно использовать RAII, от «Си с классами» остается уже очень мало.
Меня интересуют конкретные примеры предупреждений в Visual C++, которые «относятся к стилю».
DRY — отлично, но каждый раз как в коде встречается #include, код из заголовка копируется в текущую единицу трансляции. Кстати, в тексте поста об этом тоже говорится.
int->long действительно все равно как приводить, а в случае указателей есть разница.
Сложно проверить, что человек действительно хорошо понимает, что делает. На вопросы он, скажем, все ответит, но это не гарантия хорошего понимания и способности правильно применить знания в сложной ситуации.
Кстати, о пилотах. В самолете есть так называемый авиагоризонт — устройство, показывающее наклон самолета. Он может быть реализован одним из двух способов. Либо профиль самолета изображается всегда горизонтальным, а реальный горизонт изображается наклоненным относительно него, либо наоборот — горизонт отображается неподвижным, а самолет изображается наклоненным. Очевидно, что один и тот же реальный наклон самолета в этих двух системах показывается противоположным образом. Не могу утверждать этого сам, но не раз слышал, что часть аварий происходит, когда пилот, летавший много лет на самолете с авиагоризонтом одного типа и переученный на самолет с авиагоризонтом другого типа при нештатной ситуации выполняет маневр, противоположный необходимому, и именно это приводит к аварии.
Это я к тому, что формальная аттестация очень далека от идеала.
Я знаю, что вы иронизируете, но сейчас вы озвучили распространенное заблуждение. Почему-то считается, что нужно выдавать как можно больше предупреждений, от этого анализ как будто становится полнее и полезнее. На самом деле, конечно, нужно выдавать как можно больше полезных предупреждений, иначе пользователь просто перестанет реагировать на шум и будет глушить предупреждения, «чтобы не мешали».
С константной строкой не намного лучше. Например, в Visual C++ runtime есть _vsnwprintf_s() — недавно нашли случай, когда в нее в качестве строки форматирования подавалась строка с именем файла, содержащим многочисленные символы "%", функция просила под результат форматирования больше памяти, чем можно было выделить в программе (типа пару гигабайт), вызывающий код выдавал ошибку «недостаточно памяти».