変更はいつ反映されますか。欠陥を修正し、残りは無視します。プロジェクトファイルが見つかりません。ビルドのロードが失敗しました。超える同じ欠陥がある場合は、テーブルを読みこめません。サーバーとの接続が失われました。問題ポート上のエージェントを起動できませんでしたデフォルト以外の場所を使用するとプロジェクト名が保存されないプロジェクトナビゲーターでファイルが淡色表示されます。ファイルまたはプロジェクトを解析できません。マシンのシャットダウン時のライセンスサーバーエラーライセンスを取得できません。インストール先が見つかりません。プロジェクトファイルが見つかりません。ファイルの作成:解析へのファイルの適用:完全ビルド解析を実行します。解析の精度を高めることができます。種類の見方があります。解析のチューニング方法について説明します。解析中の条件付きコンパイルを利用して、コンパイラに別のバージョンのソースコードを提供します。コード内で認識するマクロを抑制または置換します。マクロよりも多少制限されていますが、ソースコードの変更が不要です。よるコード動作の解釈を変更するために、コードの特定関数をチューニングします。レコードを作成することができます。この記事のウォークスルー例では、これらのチューニング方法を使用するための一般的なシナリオについて説明します。コードで広く使用されています。ポインターの引数を予期する場合は、次のようなコードを使用します。}静的解析ツールがコード内のアサートを認識し、条件チェックとして適切に処理することが重要になります。マクロを定義することが一般的です。通常標準バージョンはエラーが発生した条件、ファイル名、および行番号を表示しますが、カスタムアサートでは、エラーメッセージに関数またはモジュール名を追加したり、一部のロギングシステムからファイルにエラーを報告することができます。製品のデバッグバージョンでは、アサートを定義して拡張エラーレポートを実装するか、デバッガーを自動的に起動できますが、アサートのリリースバージョンでは、空のステートメントに拡張して追加健全性チェックのオーバーヘッドを排除できます。条件に応じてコンパイルしたコードをソースに追加する手段は、異なる環境に対応するために一般的に使用されています。実行中のみに特定のコードが有効になり、それ以外の場合はコードが無視されます。ブロックにアサートタイプのマクロの別の定義を追加する場合は、コードを変更する必要がなく、管理がシンプルになります。次のコードがあるとします。報告する可能性があります。より簡単で、より標準的なカスタムアセットの定義を送ることで、これが発生する確率を下げることができます。合わせてソースコードを変更する必要があります。コードに必要な変更がいくつかのマクロ定義に限定されている場合は、オーバーライドファイルを使用してソースの変更を回避できます。プロジェクトにインポートするヘッダーファイルです。コンパイラは、プロジェクトにビルドされたすべてのソースモジュールに自動的にオーバーライドファイルを含めて処理します。運用中のソースに次のマクロ定義が含まれるとします。__FUNCTION__))コンパイラによりシンプルで直接的なアサートを使用するには、次の定義を含むオーバーライドファイルを作成できます。専用定義に拡張されます。}その一方で、運用中のコンパイラは引き続き元の定義を使用してマクロを拡張します。ディレクティブは、運用中のソースに定義されたマクロのみに影響します。