ライブラリヘッダーからのGCC警告を抑制する方法は?


126

ヘッダーが大量の(繰り返し)警告を生成するlog4cxx、boostなどのライブラリを使用するプロジェクトがあります。ライブラリインクルード(つまり#include <some-header.h>)または特定のパスからのインクルードからの警告を抑制する方法はありますか?関連する情報が不明瞭にならないように、プロジェクトコードで通常どおり-Wallや-Wextraを使用したいと思います。私は現在、make出力でgrepを使用していますが、もっと良いものが欲しいです。

回答:


127

-isystem代わりにを使用して、ライブラリヘッダーを含めることができ-Iます。これはそれらを「システムヘッダー」にし、GCCはそれらの警告を報告しません。


11
XCodeでこれを実行しようとしている場合は、ターゲットビルド設定の「カスタムコンパイラフラグ」の「他のC ++フラグ」に-isystemパスを貼り付けます。
Matt Parkins、

3
潜在的な欠点の1つは、一部のプラットフォームでは、g ++がでシステムヘッダーを自動的にラップextern "C"するため#include-isystemパスにC ++ヘッダーがある場合、C リンケージに関する奇妙なエラーが発生することです。
Tavian Barnes、2016

1
+1は、迷惑なブースト警告に関する問題を解決するのに役立ちましたstackoverflow.com/questions/35704753/warnings-from-boost
mrgloom

3
なぜこれは、1.5時間前にまったく同じことを言ったOP自身の回答よりもはるかに多くの票を持っているのですか?
underscore_d

1
Xcodeの場合:ターゲットビルド設定の「その他のC ++フラグ」にフォルダーパスがない場合はどうなりますか?誰かがこのソリューションについて詳しく説明できますか?
Ossir

107

CMakeを使用している場合は、include_directoriesディレクティブを変更して、そのSYSTEMようなヘッダーに対する警告を抑制する記号を含めることができます。

include_directories(SYSTEM "${LIB_DIR}/Include")
                    ^^^^^^

ライブラリ${LIBFOO_USE_FILE}がCMakeのinclude()コマンドで使用される変数を提供する場合はどうなりますか?
2016年

2
これはほとんど私の問題の解決策のようです。私は1.)バイナリターゲットを使用しています。これは、2。)に依存する、自分で記述したヘッダーのみのターゲットです。これは、3。)一部の外部ライブラリに依存しています。1と2の警告のみを取得する方法がわかりません。何かアイデアはありますか?
knedlsepp

2
動作していないようです。を使用するプロジェクトでこれを試しましたが、それが存在するフォルダーがオプションに含まれている場合でもeasylogging++、同じ大量の警告が表示easylogging++.hされSYSTEMます。
rbaleksandar

これをありがとう。それは私を警告のページとページから救いました。
Svalorzen 2018年

1
受け入れられた回答と同じコメント:これは私にとって悪い習慣です。
ラフィ

55

プラグマを使用できます。例えば:

// save diagnostic state
#pragma GCC diagnostic push 

// turn off the specific warning. Can also use "-Wall"
#pragma GCC diagnostic ignored "-Wunused-but-set-variable"

#include <boost/uuid/uuid.hpp>
#include <boost/uuid/uuid_generators.hpp>
#include <boost/uuid/uuid_io.hpp>
#include <boost/lexical_cast.hpp>

// turn the warnings back on
#pragma GCC diagnostic pop

3
GCCでのみ利用可能> = 4.6
Caduchon 2015年

1
push / popプラグマの機能が大好きです。私は何年も前に利用可能だったJavaのようなものや、C / C ++に不満/嫉妬していることを覚えています。私はこれが利用できることを気に入っていますgcc
Trevor Boyd Smith

@TrevorBoydSmith MSにclも長年の能力があります... gcc適応するのが少し遅い場合があります。
Alexis Wilke

29

私はトリックを見つけました。makefile で-Idir使用する代わりに、ライブラリインクルードの場合-isystem dir。その後、GCCはブーストなどをシステムが含む警告として処理し、無視します。


プリコンパイル済みヘッダーを使用する場合は、ヘッダーとコードの両方をコンパイルするときにフラグを追加する必要があることに注意してください。
user202729

9

#pragmaコンパイラーへの指示です。#includeの前に何かを設定し、後で無効にすることができます。

コマンドラインでも実行できますます。

特に警告の無効化に関する別のGCCページ

ソースコード内で#pragmaを使用してから、サウンドを提供するオプションを選択します 、あなたが警告を無効にしている理由の(コメントなど)の理由を。これは、ヘッダーファイルについての推論を意味します。

GCCはこれを分類することによってこれに取り組みますは警告タイプをことでます。警告として分類することも、無視することもできます。以前にリンクされた記事には、無効にされている可能性のある警告が表示されます。

注:属性を使用して、ソースコードをマッサージして特定の警告を防ぐこともできます。ただし、これはGCCに非常に密接に結びついています。

注2:GCCは、Microsoftのコンパイラで使用されているpop / pushインターフェースも使用します。Microsoftは、このインターフェースを通じて警告を無効にします。それが可能かどうかさえわからないので、これをさらに調査することをお勧めします。


プラグマを検討しましたが、ヘッダーを含める前に警告を抑制した場合、#includeの後にそれを以前の状態に戻すにはどうすればよいですか?プロジェクトコードのすべての警告を確認したいのですが(既に数回助けられました)、コマンドラインから制御できます。
AdSR、2009

4

プリコンパイル済みヘッダーを使用してみてください。警告は消えませんが、少なくともメインの編集では表示されません。


1
これは実際には良い考えかもしれません。サードパーティのインクルードは毎日変更されません。
AdSR 09

丁度。Linuxではあまり使用していませんが、Visual Studioではかなりうまく機能します。
Pablo Santa Cruz、

あなたがそれらを抑制するために、いくつかの他の方法(例えば使用しない限り、彼らはまだコンパイルに表示されます-isystemが、ヘッダーをコンパイルするには、コードの両方でそれを使用することを忘れない)
user202729


1

以下を入れて

#pragma GCC system_header

このファイル内の次のすべてのコードのGCC警告をオフにします。


-9

これらの警告には理由があるはずです。これらは、ライブラリを使用するコードのエラー、またはライブラリコード自体のエラーが原因で発生します。最初のケースでは、コードを修正します。2番目のケースでは、ライブラリの使用を停止するか、FOSSコードの場合は修正します。


+1は良いアドバイスです:Dが具体的な方法を尋ねています:D
Hassan Syed

4
特にサードパーティのコード、特に Boostのようなメタプログラミングが豊富なコードでは、一部の警告を修正することが不可能または非常に困難です。
ulidtko

3
さらに悪いのは、「cのシャドウの宣言がthisのメンバーである[-Werror = shadow]」というブーストヘッダーの深い部分です。それは確かに問題ではありませんが、それと同様の問題が出力を吐き出していて、インスタンスをコードベースで本当の影で見つけるのを難しくしています。
dmckee ---元モデレーターの子猫
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.