したがって、Visual C ++でこの警告をかき消したいのですが...

不合格 通常の状況:あなたは完璧に正しいコードを書きましたが、Visual C ++は警告をスローします。 多くの場合、警告をなくすようにコードを少し書き直すことができますが、常にではありません。そして、この警告の発行を抑制するための唯一の方法があります。



Visual C ++でこれを行う機会と、それらを使用するときに発生するエラーについて考えてみましょう。







最も明白な最初の可能性は、プロジェクトレベルでプロジェクト設定の警告を無効にすることです 。 それは動作しますが、ひどく。 まず、このプロジェクトに含まれるすべてのヘッダーを含め、プロジェクト全体で警告が沈黙します。 次に、コードを別のプロジェクトにコピーすると、警告が再び表示されます。 これは、ヘッダーファイル内のコード(テンプレートの実装を含むなど)の場合に必ず発生します。これらのコードは、テンプレートを使用する各プロジェクトに含める(#include)必要があります。



次のオプションは、ファイルレベルでプロジェクト設定の警告を無効にすることです 。 この方法は、前の方法よりもさらに悪いです。 まず、警告は放送ユニット全体、つまり このファイルとそれに含まれるすべてのヘッダー。 第二に、前回と同じコードのコピーに関するまったく同じ問題。 第三に、プロジェクトに数個以上のファイルがあるとすぐに、プロジェクトをVisual C ++の新しいバージョンに変換するときにこの設定が失われる可能性は1よりわずかに少なくなります。



#pragma warningを使用したままです。 通常、次のように使用されます。



 #pragma warning (disable: 9000) // ,   C9000 #pragma warning (default: 9000)
      
      









...そして、彼ら自身にとても満足しています。 警告は沈黙し、コードが作成され、警告が復元されました。 利益。



実際、これはFAILです。 #pragma warning(デフォルト)の説明を注意深く読んでください(はい、注意深く、はい、読んで、どこからでもコードをコピーして貼り付けないでください)。 次のように言います:このデザイン



1.アラートのデフォルトレベルを設定し、

2.警告を含む。



レベルが最初です。 Visual C ++では、1〜4の数字が各アラートに関連付けられています-これはアラートレベルです。 レベル1の警告はより深刻であると見なされ、レベルが上がると、重大度はおそらく低下します。 各警告にはデフォルトのレベルがあります。 建設業



 #pragma warning(Level: Warning)
      
      





その中に示されている警告レベルを設定し、警告をオンにします。 レベルは固定されていませんが、変更できます。



コンパイラには、警告レベルを表示する警告レベルの設定があります。 この設定の値がAに等しい場合、特定のコード行で警告が表示されるのは、そこで有効になっており、レベルがA以下である場合のみです。



さらに、Visual C ++では、最も無害なコードでも警告が発行されるため、一部の警告はデフォルトでオフになっています。 特定の警告のピンポイント抑制のアイデアに激怒しようとしているすべての人に、まずこの事実を認識し、感じてもらいましょう。



#pragma warning(デフォルト)を使用したときにFAILがどのように現れるかを見てみましょう。



失敗1 警告C9001はデフォルトでオフになっています。 ヘッダーファイルのコードは、#pragma warning(デフォルト:9001)を使用して、小さなコードでミュートされた警告を「復元」します。



警告がすでにオフになっている場合、なぜ彼はこれを行うのでしょうか? デフォルトでオフになっている警告のリストは、Visual C ++のバージョンによって異なります-警告は徐々に追加されます。 コードが最初にVisual C ++ 7用に作成され、C9001がデフォルトでオンになっていて、Visual C ++ 10でコンパイルされ、警告がすでにオフになっている場合、この設計は意味をなさないが、単純に継承できます。



その結果、#pragma warning(デフォルト)は、デフォルトで警告を強制的にオフにします。



失敗2 。 警告C9002のデフォルトレベルは3で、プロジェクトはレベル2でコンパイルされます。 警告レベル2以下を表示します。 多くの熟考の後、開発者は、実際には、C9002警告はレベル2でそれを尊重するのに十分なほど深刻であると判断しました。 強制的に重大度を上げます。 したがって、各プロジェクトには標準タイトルが含まれています。このタイトルは、すべての翻訳単位に分類され、#pragma構築警告(2:9002)が含まれています。



翻訳単位のテキストの少し下が#pragma warning(デフォルト:9002)です。これはレベルを3にリセットし、レベル2でコンパイルする場合、警告は発行されません。 ところで、この警告は重大な欠陥を報告しました。 私たちは微笑んで振ります。 逆方向にも機能します-レベル2以下でコンパイルされたプロジェクトで発行されるのを防ぐために警告レベルを2から3に上げました(つまり、重大度を下げました)が、#pragma warning(デフォルト)はレベルを2にリセットしますそして、警告が発行されます。



失敗3 警告C9003はデフォルトで有効になっていますが、ケースで発行されたときに誰も思い出せないほど貧弱に考えられています。 開発者は、共通のヘッダーファイルで#pragma warning(disable:9003)を使用して、どこでもそれをdrれさせることにしました。 翻訳単位の下には#pragma warning(デフォルト:9003)があり、これには警告が含まれています。



特に快適なのは、これらの状況が適切なタイミングで発生することです。あるバージョンのコンパイラーから別のバージョンに切り替えるとき、既に使いにくいプロジェクトに多数のサードパーティコードを含めようとするとき、2番目の状況は単に警告の抑制につながります、その結果、後でユーザーがDarwin Awardを獲得するのに役立つコードのバグをスキップします。



実際、次のように警告を抑制する必要があります。



 #pragma warning(push) // ,  : www.abbyy.ru/vacancy #pragma warning(disable:9000) //    C9000 #pragma warning(pop)
      
      





最初の設計ではアラート設定の現在の状態が保存され、2番目の設計では目的の警告が無効になり、3番目の設計では保存された状態が復元されます。 この場合、状態は完全に復元されます。上記のレベルで行われたすべての変更も復元され、デフォルトでオフになっている警告はオンになりません。



怖いように見えますが、同じ10億のエラーを見逃さないためにできないことです。



ドミトリー・メッシェリャコフ、



開発者製品部門



All Articles