警告を有効にする必要があるのはなぜですか?

C および C++ コンパイラは、次のような一般的なプログラマのミスをデフォルトで報告するのが非常に苦手です。

• 変数の初期化を忘れる
• return関数からの値を忘れる
• printfおよびファミリ内の引数scanfがフォーマット文字列と一致しません
• 関数が事前に宣言されずに使用される (C のみ)

これらは検出および報告できますが、通常はデフォルトではありません。この機能は、コンパイラ オプションを介して明示的に要求する必要があります。

警告を有効にするにはどうすればいいですか?

これはコンパイラによって異なります。

Microsoft C および C++ コンパイラは/W1、、、、/W2などのスイッチを認識します。少なくとも を使用してください/W3。システムヘッダー ファイルに対して誤った警告が出力される可能性がありますが、プロジェクトがこれらのオプションのいずれかを使用して正常にコンパイルされる場合は、そのまま使用してください。これらのオプションは相互に排他的です。/W4/Wall/W3/W4/Wall

他のほとんどのコンパイラは次のようなオプションを理解します。-Wall、-Wpedanticそして-Wextraは-Wall必須で、残りはすべて推奨されます (名前に反して、すべて-Wallの警告ではなく最も重要な警告のみが有効になることに注意してください)。これらのオプションは、個別に使用することも、すべて一緒に使用することもできます。

IDE には、ユーザー インターフェイスからこれらを有効にする方法がある場合があります。

なぜ警告をエラーとして扱う必要があるのでしょうか? それらは単なる警告です!

コンパイラの警告は、コードに潜在的に重大な問題があることを示しています。上記の問題は、ほとんどの場合致命的です。他の問題は致命的である場合もそうでない場合もありますが、たとえ誤報であったとしてもコンパイルが失敗するようにする必要があります。各警告を調査し、根本原因を見つけて修正してください。誤報の場合は、回避策を講じます。つまり、別の言語機能または構造を使用して、警告がトリガーされないようにするのです。これが非常に難しい場合は、ケースごとにその特定の警告を無効にしてください。

警告がすべて誤報であっても、警告を警告のままにしておくのは望ましくありません。発行される警告の総数が 7 未満の非常に小規模なプロジェクトであれば、問題ないかもしれません。それ以上になると、新しい警告が古い警告の洪水の中に埋もれてしまう可能性が高くなります。そのようなことは許さないでください。プロジェクト全体がクリーンにコンパイルされるようにしてください。

これはプログラム開発に当てはまります。プロジェクトをソースコード形式で世界に公開する場合は、提供しない方が良いかもしれません。-Werrorまたは、リリースされたビルド スクリプトに同等のものを記述します。他のユーザーは、異なるバージョンのコンパイラや、異なる一連の警告が有効になっている可能性のあるまったく異なるコンパイラを使用してプロジェクトをビルドしようとする可能性があります。そのビルドが成功することを望むかもしれません。それでも、警告メッセージを見たユーザーがバグ レポートやパッチを送信できるように、警告を有効にしておくことをお勧めします。

警告をエラーとして扱うにはどうすればよいですか?

これもコンパイラ スイッチを使用して実行されます。/WXは Microsoft 用で、他のほとんどの人は を使用します-Werror。どちらの場合でも、警告が生成されるとコンパイルは失敗します。

これで十分ですか？

おそらくそうではありません。最適化レベルを上げると、コンパイラはコードをより詳細に調べるようになり、この詳細な調査によってさらに多くの間違いが明らかになることがあります。したがって、警告スイッチだけで満足せず、最適化を有効にしてコンパイルするときには常に警告スイッチを使用してください (-O2または-O3、/O2MSVC を使用している場合は または )。