После смешивания с водой кислота разбавится до крайне низких конценраций, и это спасет рыбок от растворения. Если о чем и беспокоиться, то о попавшем в воду свинце.
С вашей точки зрения проект не сильно меняется, потому что вы правите мало строк. Но ваши правки строк могут очень сильно влиять на код. Например, вы правите «один жалкий макрос», а этот макрос разворачивается в десятках тысяч мест в коде. Или вы правите одну строку в шаблоне, а шаблон — не конечный код, это только заготовка, которая используется десятки и сотни раз с разными параметрами и каждый раз получается новый класс или новая функция — правка на них повлияет. Так что одна правка может очень сильно повлиять на выходной файл. Учтите, что PGO управляет генерацией машинного кода — т.е. самой последней стадией. Если что-то там отъедет, вы будете это отлаживать до конца дней. На мой взгляд, это очень рискованная затея.
Интересно вот что. Предположим, я собираю программу с PGO и в моем профилировочном пакете данные немного не такие (насколько не такие — не знаю), как будут у реальных пользователей. Станет ли моя программа работать у реальных пользователей медленнее, чем если бы она была собрана без PGO? Если да, то какого ухудшения мне ждать?
Да, но здесь снова ирония. Прежде чем люди согласятся пользоваться статическим анализом постоянно, хорошо бы, чтобы они основательно попробовали его один раз ну или хотя бы внимательно посмотрели на список дефектов, которые вы находите и им присылаете, а они даже последнего сделать не могут.
При этом не надо забывать, что многие разработчики до этого состояния не доходят никогда. Хотя бы потому что качество кода — что-то эфемерное и занудное, а попробовать новый фреймворк или прикрутить новые фичи очень хочется.
Во-первых, все заметные и важные ошибки обычно вылавливают другими способами. Программа падает — отладили, исправили. На такие обзоры остаются те ошибки, которые не проявились достаточно ярко, чтобы их начали искать.
Во-вторых, оставшиеся ошибки вообще не обязаны очевидно проявляться. Где-то на вход подаются только такие данные, при которых ошибка не проявляется. Где-то ошибка проявляется, но код вызывается крайне редко. В итоге ошибок, которые хотя бы как-то заметно проявляются при реальной работе, очень мало.
Это такая ирония — вроде бы статический анализ много чего нашел и должен дать улучшение качества кода, а по факту измерить это улучшение совсем не просто.
ошибки, которые могут стоить очень дорого (к примеру уязвимости)
Не понимаю этой логики. Почему-то уязвимость — это сразу серьезная проблема, а если, скажем текст, в редакторе иногда искажается (это я привел гипотетический пример проблемы, которая в принципе могла бы быть в Notepad++), и это мешает работать, то это уже как будто и не проблема. Нашли уязвимость — хорошо, нашли какой-нибудь мелкий дефект в редакторе, из-за которого не так прыгает каретка, — тоже хорошо.
С одной стороны, компилятор вроде как хочет помочь и предупреждает, что «вот тут вы может быть имели в виду что-то другое» и неплохо бы поставить скобки, чтобы было понятнее. С другой стороны, в сложном выражении добавление кучи скобок часто ухудшает понимание.
Почему так происходит? Потому что предупреждение плохо продумано. В большинстве случаев ситуация, когда «неплохо бы поставить скобки», сопровождается значительной сложностью выражения. Компилятору бы предложить расписать это выражение на несколько, а он выдает не особо полезное предупреждение. Пользователь глушит предупреждение, формально все в порядке, но однажды можно посадить ошибку в код.
Не полетит. На первый взгляд, это мотивирует разработчиков делать так, чтобы «чертов компилятор не выдавал предупреждений», а на самом деле — это мотивирует их «сделать что угодно, чтобы руководство не доставало». Разработчики будут тупо глушить предупреждения или портить код, чтобы предупреждения не выдавались.
Заметьте, я не предлагаю игнорировать все предупреждения, я только привожу этот способ как один из реально используемых на практике.
Скомпилировать сервер, чтобы он отдавал другую версию, — очень здравая мысль, я бы и не стал называть это паранойей. Одно но — по железу в стойке не видно, что внутри за сервер, так что пример немного не по теме.
Про производительность понял, спасибо за хороший пример.
Я не буду за это агитировать, но один из способов — игнорировать все. По факту C++ дает кучу возможностей отстрелить себе ногу и все остальные части тела, которые никакие предупреждения компилятора выявить не помогут. Соответственно, логика у этого способа такая: в коде и так много что много где может сломаться, так что предупреждением больше, предупреждением меньше — на погоду не влияет. С виду работает — и ладно.
Как пользоваться? По сути — никак не пользоваться.
Смысл статического анализа примерно в следующем: не знающая усталости программа может перепахать тонны кода и очень надежно найти там некоторые закономерности, возможно, указывающие на наличие ошибки.
Если ее сообщения достаточно часто содержат действительно полезные предупреждения, вы получаете бонус от использования — программа ловит вас за руку при каждой проверке, в результате внесенные в код проблемы не просачиваются даже в репозиторий.
Тогда логично, чтобы анализ выполнялся после каждой правки (PVS-Studio это делает в режиме инкрементального анализа). Это при условии, что шума не слишком много, иначе вы тратите время на разбирательство — проблема там или нет и только замусориваете код вставками для подавления предупреждения.
Попробуйте для развлечения скомпилировать SQLite3 — просто возьмите все исходники, добавьте их в проект и скомпилируйте. Предупреждений будут сотни, но никто же из-за этого не отказывается от использования SQLite.
С вашей точки зрения проект не сильно меняется, потому что вы правите мало строк. Но ваши правки строк могут очень сильно влиять на код. Например, вы правите «один жалкий макрос», а этот макрос разворачивается в десятках тысяч мест в коде. Или вы правите одну строку в шаблоне, а шаблон — не конечный код, это только заготовка, которая используется десятки и сотни раз с разными параметрами и каждый раз получается новый класс или новая функция — правка на них повлияет. Так что одна правка может очень сильно повлиять на выходной файл. Учтите, что PGO управляет генерацией машинного кода — т.е. самой последней стадией. Если что-то там отъедет, вы будете это отлаживать до конца дней. На мой взгляд, это очень рискованная затея.
Во-первых, все заметные и важные ошибки обычно вылавливают другими способами. Программа падает — отладили, исправили. На такие обзоры остаются те ошибки, которые не проявились достаточно ярко, чтобы их начали искать.
Во-вторых, оставшиеся ошибки вообще не обязаны очевидно проявляться. Где-то на вход подаются только такие данные, при которых ошибка не проявляется. Где-то ошибка проявляется, но код вызывается крайне редко. В итоге ошибок, которые хотя бы как-то заметно проявляются при реальной работе, очень мало.
Это такая ирония — вроде бы статический анализ много чего нашел и должен дать улучшение качества кода, а по факту измерить это улучшение совсем не просто.
Не понимаю этой логики. Почему-то уязвимость — это сразу серьезная проблема, а если, скажем текст, в редакторе иногда искажается (это я привел гипотетический пример проблемы, которая в принципе могла бы быть в Notepad++), и это мешает работать, то это уже как будто и не проблема. Нашли уязвимость — хорошо, нашли какой-нибудь мелкий дефект в редакторе, из-за которого не так прыгает каретка, — тоже хорошо.
Отличный пример.
С одной стороны, компилятор вроде как хочет помочь и предупреждает, что «вот тут вы может быть имели в виду что-то другое» и неплохо бы поставить скобки, чтобы было понятнее. С другой стороны, в сложном выражении добавление кучи скобок часто ухудшает понимание.
Почему так происходит? Потому что предупреждение плохо продумано. В большинстве случаев ситуация, когда «неплохо бы поставить скобки», сопровождается значительной сложностью выражения. Компилятору бы предложить расписать это выражение на несколько, а он выдает не особо полезное предупреждение. Пользователь глушит предупреждение, формально все в порядке, но однажды можно посадить ошибку в код.
Заметьте, я не предлагаю игнорировать все предупреждения, я только привожу этот способ как один из реально используемых на практике.
Про производительность понял, спасибо за хороший пример.
Как пользоваться? По сути — никак не пользоваться.
Любопытно, о чем здесь речь.
Если ее сообщения достаточно часто содержат действительно полезные предупреждения, вы получаете бонус от использования — программа ловит вас за руку при каждой проверке, в результате внесенные в код проблемы не просачиваются даже в репозиторий.
Тогда логично, чтобы анализ выполнялся после каждой правки (PVS-Studio это делает в режиме инкрементального анализа). Это при условии, что шума не слишком много, иначе вы тратите время на разбирательство — проблема там или нет и только замусориваете код вставками для подавления предупреждения.
Почему удаляют? Считают спамом?