ガイドラインサポートライブラリチェッカーを私のプロジェクトに統合しています。私はそれを実行するとgsl :: include includeステートメント
Microsoft.CppCoreCheck
Microsoft.Gsl
は私が
一つの具体的な例としては、私はsdl_stdinc.hに警告を得るSDL.hであるなどの標準ライブラリ、GLM、ブースト、などの含まれたライブラリからエラーの束を取得します。
ExtSDL.hpp私は、静的コード解析から、このライブラリを除外する方法についての情報を見つけることができません
#pragma once
#pragma warning(disable: 4710)
#pragma warning(push, 0)
#include <SDL.h>
#pragma warning(pop)
： 私は私の管理下に一つだけのヘッダを経由して、私はSDLが含まれていることを確認しました。 GSLチェッカーのための警告を黙らます
私がこれまでに見つかった中で最も実用的なアプローチは#defines
#define SDL_WARNINGS 4710 26135
を構築することであり、その後、#include他の人の汚いコードthusly
#pragma warning(push)
#pragma warning(disable: SDL_WARNINGS)
#include <SDL.h>
#pragma warning(pop)
、上記のC26135などの関連する警告コードに基づいています。コンパイラは静かにしたい場所でコンパイラを無音にします。警告の無効化は、プッシュ/ポップのスコープに対してローカルであることに注意してください。
このようなアプローチでは、gslを含む追加のチェックをオンにしても/ Wall/WXをコンパイルできます。クリティカルに警告していない他の人のヘッダに依存している場合でも、重大なことです。残念ながらこれには、私が見てきたすべてのCおよびC++標準ライブラリの実装と、Boost、LLVM、Windows SDKなどが含まれます。つまり、基本的にすべてです。さらに、警告プラグマを変更する悪意のあるヘッダからあなたを守ります（これを行うのに使用されているいくつかの標準的なライブラリ実装ですが...）。このアプローチでは、依存するドロスよりも高いレベルのクリーン度と品質に独自のコードを持ち上げることができます。
Microsoft C++コアチェックの優れた点の1つは、警告に使用される通常のメカニズムに結びつけた方法です。このアプローチは、追加のルールセットの定期的な警告とチェッカーに対して一様に機能します。 gslチェッカーのいくつかは疑問があり、多くの既存のコーディングスタイルと互換性がありません。つまり、標準標準のベンダーライブラリを#includeするコードでgslをオンにして、無効にするための警告コードを長く作成する必要があります。ノイズをダイアルする前に自分のコードに集中することができます。もちろん、グローバルに#pragma warning(disable: GSL_CHECKERS_YOU_DONT_LIKE)に独自のコードを記述することができますので、その面白いところに集中することができます。
また、使用するルールセットを選択したり、カスタムルールセットを作成して、適用するルールを選択することもできます。これはおそらく、コード解析が有効になっているほど速くないビルド時間を最小限に抑えることになるでしょう。
あなたが「他の人のもの」のチェッカーを無効にできるため、本質的に汚れたヘッダーを素早く作成することができます。明らかな機能要求ですが、サポートされていることはわかりません。おそらく、それを実装することはかなり簡単だろう。指定されたディレクトリのセットにあるソースコード上でチェッカーを実行するだけです。＃がそのゾーンの外に出ると、チェッカーは自動的に無効になります。 Microsoftの誰かがこれを読んでいますか？