Комментарии 27
Ай-ай-ай, реклама в коде.
К чести M$ можно сказать, что в VS хотя бы можно узнать код предупреждения, чтобы его отключить. А в gcc эти коды запрятаны неведомо куда. Поэтому лучше переписывать каждый раз код, чтобы компилятор не смог ни к чему придраться.
К чести M$ можно сказать, что в VS хотя бы можно узнать код предупреждения, чтобы его отключить. А в gcc эти коды запрятаны неведомо куда. Поэтому лучше переписывать каждый раз код, чтобы компилятор не смог ни к чему придраться.
Переписать код так, чтобы компилятор не смог ни к чему придраться не всегда возможно, особенно если в проекте поставлены параноидальные настройки. Тоже можно сделать и в XCode:
clang / GCC — в зависимости от используемого компилятора.
А сам код ("-Warc-performSelector-leaks" например) можно узнать в Log Navigator.
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
// код с предупреждением
#pragma clang diagnostic popclang / GCC — в зависимости от используемого компилятора.
А сам код ("-Warc-performSelector-leaks" например) можно узнать в Log Navigator.
Я обычно пишу код с самыми параноидальными настройками (за исключением разве что -Wunreachable-code) — уменьшать уровень параноидальности приходится в основном из-за boost/qt и прочих сторонних библиотек, чьи заголовки с параноидальными настройками сразу ломаются.
«Тоже можно сделать и в XCode»
Это пошло из gcc (способ работает в том числе и на линуксе), XCode тут непричем.
Это пошло из gcc (способ работает в том числе и на линуксе), XCode тут непричем.
Разрешите взоразить. Предупреждения, они обычно неспроста. А значит, код не идеален. А раз код не идеален, значит нужно его исправить, а не заглушить предупреждение. И да, это относится даже к самым параноидальным уровням настройкам.
… И кстати да, ИМХО глушение предупреждений — просто костыль.
… И кстати да, ИМХО глушение предупреждений — просто костыль.
p.s. Если я не вернусь, прошу считать меня Code Nazi.
Интересная мысль. В Visual C++ 10 по умолчанию выключены несколько десятков предупреждений. Как вы думаете, почему?
Потому, что некоторые из них необязательны, и ЕМНИП есть даже взаимоисключающие. Вы выбираете такой набор, который подходит вашему стилю разработки, и строго придерживаетесь его. А делать в одном месте так, а в другом — воттак — ИМО плохой стиль, со всеми вытекающими.
Это просто прекрасно. С одной стороны — предупреждения неспроста, с другой — необязательны. И кто-то еще должен раз и навсегда решить, какие из них важные, а какие нет.
Не могу сказать ничего о предупреждениях в MSVS, но в гцц есть, например:
- -Wunreachable-code, который довольно часто выдаётся в библиотеках;
- -Wreorder, который, как правило, роли не играет;
-Wold-style-cast, от которого тоже никакого профита — кому, кроме pure C++-наци, какая разница, каким способом я скастую int в long, сишный способ просто короче;
И эти совершенно незначительные предупреждения вместе с -Werror сломают компиляцию.
Ох, чёрт, потерял закрывающий </b> после «как правило».
>-Wold-style-cast, от которого тоже никакого профита — кому, кроме pure C++-наци, какая разница, каким способом я скастую int в long, сишный способ просто короче;
int->long действительно все равно как приводить, а в случае указателей есть разница.
int->long действительно все равно как приводить, а в случае указателей есть разница.
Да нет никакой разницы, какие именно предупреждения вы для себя решили считать важными, а какие — нет. Единственное, что существенно — это то, что те, которые решили считать важными, считаются важными повсюду. Тоесть — по всему проекту. И если мы решаем использовать сишный каст — пожалуйста, только давайте будем использовать его всюду, а не как Бог на душу положит… В особенности обрамляя те места, где захотелось, дополнительными pragmaми.
Именно поэтому я считаю, что
1) настройки предупреждений должны быть на уровне проекта, а не размазаны по исходникам.
2) задавливание предупреждения в коде должно быть настолько исключительным, что на него должно получать визу у техлида, или что-то в этом роде, и сопровождаться детальным комментом, зачем и почему, и для чего, и почему нельзя это обойти. За мои семь с хвостиком лет работы я видел аж один такой случай, и я до сих пор сомневаюсь, нельзя ли было там сделать лучше.
Зачем такая жестокость? Чтоб в один прекрасный день не найти задавленные каким-нибудь джуниором присвоение в if-е, чисто чтоб компилилось.
p.s. аргумент в статье о копировании кода считаю смешным. DRY.
Именно поэтому я считаю, что
1) настройки предупреждений должны быть на уровне проекта, а не размазаны по исходникам.
2) задавливание предупреждения в коде должно быть настолько исключительным, что на него должно получать визу у техлида, или что-то в этом роде, и сопровождаться детальным комментом, зачем и почему, и для чего, и почему нельзя это обойти. За мои семь с хвостиком лет работы я видел аж один такой случай, и я до сих пор сомневаюсь, нельзя ли было там сделать лучше.
Зачем такая жестокость? Чтоб в один прекрасный день не найти задавленные каким-нибудь джуниором присвоение в if-е, чисто чтоб компилилось.
p.s. аргумент в статье о копировании кода считаю смешным. DRY.
Пост не о том, нужно ли давить предупреждения и можно ли давить предупреждения, он о том, как их давить после получения той самой визы у техлида.
DRY — отлично, но каждый раз как в коде встречается #include, код из заголовка копируется в текущую единицу трансляции. Кстати, в тексте поста об этом тоже говорится.
DRY — отлично, но каждый раз как в коде встречается #include, код из заголовка копируется в текущую единицу трансляции. Кстати, в тексте поста об этом тоже говорится.
А еще в VS есть конструкция warning:suppress — проигнорировать определенный ворнинг на ближайшей строке.
Кроме того, вместо #pragma можно писать __pragma() — в таком виде его можно использовать в макросах:
Кроме того, вместо #pragma можно писать __pragma() — в таком виде его можно использовать в макросах:
#define __const_cond( c ) \
__pragma(warning(push)) \
__pragma(warning(disable:4127)) \
( c ) \
__pragma(warning(pop))Если верить MSDN, warning:suppress работает только для предупреждений с кодом 6000 и выше.
Cсылка ведет на доку для VS2005. В более поздних такого ограничения нет (пруфлинк).
Крутняк, спасибо!
Мне очень нравится как в исходниках Chromium подобным образом борются с варнингом Compiler warning C4355: 'this': used in base member initializer list:
#define ALLOW_THIS_IN_INITIALIZER_LIST(code) MSVC_PUSH_DISABLE_WARNING(4355) \
code \
MSVC_POP_WARNING()
Foo::Foo() : x(NULL), ALLOW_THIS_IN_INITIALIZER_LIST(y(this)), z(3) {}
Прибыль?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Итак, вы хотите заглушить это предупреждение в Visual C++…