gsl :: suppress целые операторы include
Я интегрирую средства проверки библиотек поддержки директив в мой проект.
Microsoft.CppCoreCheck
Microsoft.Gsl
Когда я запускаю его, я получаю кучу ошибок из включенных библиотек, таких как стандартные библиотеки, glm, boost и т. Д.
Один конкретный пример SDL.h где я получаю предупреждения в sdl_stdinc.h,
Я убедился, что я включаю SDL только через один заголовок под моим контролем:
ExtSDL.hpp
#pragma once
#pragma warning(disable: 4710)
#pragma warning(push, 0)
#include <SDL.h>
#pragma warning(pop)
Не могу найти информацию о том, как исключить эту библиотеку из статического анализа кода.
Решение
Есть несколько способов подавления предупреждений CppCoreCheck:
- Вы можете подавить CppCoreChecks либо используя
[[GSL :: подавить (глава)]] атрибут, где глава происходит от C ++
Основные руководящие принципы, например, con.4. Пожалуйста, также посмотрите на MS документы для информации. - ты можешь использовать #pragma warning подавлять предупреждения индивидуально или навалом, как указано выше.
- Вы можете подавить все предупреждения для «не ваш код», используя CAExcludePath.
Другие решения
Наиболее практичный подход, который я нашел до сих пор, заключается в создании #defines лайк
#define SDL_WARNINGS 4710 26135
а потом #include грязный код других людей, таким образом,
#pragma warning(push)
#pragma warning(disable: SDL_WARNINGS)
#include <SDL.h>
#pragma warning(pop)
Это заставит замолчать предупреждения для контроллеров gsl, основываясь на их соответствующих кодах предупреждений, например C26135 выше. Он заглушает компилятор именно там, где вы хотите, чтобы он молчал. Обратите внимание, что отключение предупреждения местный в область push / pop.
Такой подход позволяет компилировать / Wall / WX, даже если вы включите дополнительную проверку, включая gsl. Критически это работает, даже если у вас есть зависимости от заголовков других людей, которые не предупреждают чистые. К сожалению, это включает в себя каждую реализацию стандартной библиотеки C и C ++, которую я видел, плюс Boost, LLVM, Windows SDK и т. Д. И т. Д., Т. Е. Практически все. Кроме того, он защищает вас от злых заголовков, которые изменяют предупреждающие прагмы (некоторые стандартные реализации библиотек, используемые для этого, и могут все еще …) Этот подход позволяет вам поднять свой собственный код до более высокого уровня чистоты и качества, чем зависимые от него окалины на.
Одна из хороших вещей в Microsoft C ++ Core Check заключается в том, как они связали ее с обычными механизмами, используемыми для предупреждений, поэтому этот подход работает единообразно для обычных предупреждений и проверок в дополнительных наборах правил. Слава Богу, они сделали что-то вроде этого: некоторые из контроллеров gsl довольно сомнительны и несовместимы со многими существующими стилями кодирования, т. Е. Включите gsl для кода, который включает в себя большую стандартную библиотеку поставщиков, и вам быстро нужно составить длинный список кодов предупреждений, чтобы отключить их. прежде чем вы сможете набрать шум, чтобы вы могли сосредоточиться на своем собственном коде. Конечно, вы можете глобально #pragma warning(disable: GSL_CHECKERS_YOU_DONT_LIKE) для вашего собственного кода, так что вы можете сосредоточиться на тех аспектах, которые вы найдете полезными.
В качестве альтернативы вы можете выбрать правила для применения, выбрав наборы правил для использования и / или создав индивидуальные. Предположительно это минимизирует время сборки, которое не так быстро с включенным анализом кода.
Было бы неплохо получить более прямой ответ на ваш вопрос, который по сути заставил грязные заголовки собираться быстрее, потому что вы могли бы отключить шашки для «чужих вещей». Это очевидный запрос, но я не знаю, поддерживается ли он. Предположительно это было бы довольно тривиально для реализации, например. запускать средства проверки только для исходного кода, найденного в указанном наборе каталогов, поэтому, если #include выходит за пределы этой зоны, средства проверки автоматически отключаются. Кто-нибудь в Microsoft читает это?
detector