Компилятор VC++: как определить текущий уровень предупреждения или переопределения?

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

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

Кто-нибудь знает, какую директиву компилятора я мог бы использовать или какой подход я мог бы использовать, чтобы получить эту информацию?

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

Мысли?

ПРИМЕЧАНИЯ:

Поиск по #pragma во всем моем решении дает только сбалансированные объявления предупреждения #pragma (disable: xxxx), за которым следует предупреждение #pragma (по умолчанию: xxxx). И ни одной из этих ссылок 4244.

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

Поиски по 4244 по всему MS включают пути, возвращающие несколько ссылок, которые кажутся сбалансированными или почти сбалансированными, в зависимости от символов #define, которые были установлены перед их вызовом. Отсюда мое подозрение, что виновата MS (в сочетании с предыдущей историей MS, выполнявшей небрежную работу в своих заголовках).


compiler-warnings visual-c++ pragma
person Mordachai    schedule 10.06.2009    source источник

Ответы (4)


arrow_upward
1
arrow_downward

Другой вариант — добавить это

#pragma warning (defualt)

вверху файла сразу после #includes Это сбрасывает предупреждение на значение по умолчанию, отбрасывая любое игнорирование, которое могло быть вызвано.

С другой стороны, я считаю крайне маловероятным, что заголовок Microsoft отключит предупреждение.

person shoosh    schedule 10.06.2009
comment
Этот синтаксис отклонен в VS 2008. Он хочет, чтобы конкретное предупреждение было сброшено по умолчанию. Поэтому мне пришлось бы использовать предупреждение #pragma (по умолчанию: 4244). Единственные заголовки, которые я могу найти, ссылаются на 4244: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\comdef.h( 30):#pragma warning(disable: 4244) C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\atldb.h(74):#pragma warning(disable: 4244) C:\Program Файлы (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\atldbcli.h(38):#pragma warning(disable: 4244) - person Mordachai; 10.06.2009

arrow_upward
0
arrow_downward

Вы можете просто выполнить поиск по всем заголовочным файлам для «C4244» или у вас есть доступ только к предварительно скомпилированным заголовочным файлам?

person Glen    schedule 10.06.2009

arrow_upward
0
arrow_downward

Вы можете начать с использования параметра командной строки компилятора /P< /а>. Он выводит в файл вывод препроцессора. таким образом вы действительно можете убедиться, что это действительно заголовок, который добавляет предупреждение об отключении, и попытаться собрать некоторые подсказки относительно того, какой это может быть заголовок.

person shoosh    schedule 10.06.2009

arrow_upward
0
arrow_downward

После дальнейшего расследования:

/P занимает слишком много времени (я никогда не видел, чтобы он превышал несколько файлов в течение почти часа, поэтому я отменил эту сборку)

Мне так и не удалось найти четкий способ распечатать текущий уровень предупреждения или какие-либо переопределения, действовавшие в данный момент компиляции. Таким образом, на вопрос, который я задал, на самом деле нет ответа, если только аргумент /P действительно вам не полезен (как я уже упоминал, это было непрактично для моих целей).

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

встроенный тест int (значение символа) { return ++ value; }

включать что-то

встроенный int test1 (целое значение) { return test (значение); } // должен сгенерировать C4244 - возможная потеря данных, если предыдущее #include не испортило уровень предупреждения или не переопределило предупреждение 4244.

И так далее...

В конце концов, я обнаружил, что 4244, в частности, имеет некоторые странные правила, связанные с ним, и что он эффективно отключен во всех, кроме /W4 (уровень предупреждения 4) — самый высокий уровень предупреждения. Поскольку этот уровень предупреждения очень, очень обидчив и жалуется на множество вещей, которые выходят далеко за рамки наших возможностей что-либо с ними делать, я не хотел включать /W4.

Вместо этого я поместил в наш stdafx.h PCH следующее:

pragma warning(error:4244) // это полностью включает предупреждения о возможной потере данных из-за неявного преобразования типов при любых обстоятельствах, независимо от активного уровня предупреждения

Это сработало.

Итак, MS не оставила несбалансированных предупреждений ни в одном из своих файлов, которые затронули нас. Просто 4244 очень снисходителен, за исключением самого высокого уровня предупреждения, где он в любом случае становится действительно полезным для нас.

Спасибо за вашу помощь!

person Mordachai    schedule 10.06.2009