如何禁用特定包含文件的警告？答案

【问题标题】：How to disable warnings for particular include files?如何禁用特定包含文件的警告？
【发布时间】：2011-09-13 09:23:07
【问题描述】：

我希望对特定包含文件直接或间接包含的所有文件禁用特定警告。例如，我想为 #include <bar/*> 包含的文件中包含的所有文件或文件禁用警告“您正在将字符串文字分配给 char*”（在我的例子中，星号表示“任何东西都可能在这里”） .

原因是，我必须与之一起编程的一些人不能使用“const”，所以最后我收到了很多关于特定字符串文字滥用的警告。我想忽略来自他们代码的数千条警告，这样我就可以专注于自己代码中的错误并修复它们。

我使用英特尔 C++ 和 GCC。我的一些伙伴使用clang，所以我也很高兴听到解决方案。

【问题讨论】：

stackoverflow.com/questions/1079997/… 和 stackoverflow.com/questions/965093/… 等等。
我做对了吗？如果<bar/the_file.h> 包含有问题的文件，则应禁止显示警告，而<the_file.h> 则不会？
@Neil 感谢您提供相关链接。只是为了让其他可能有一些不需要的关联的人清楚：以上两个链接不是重复链接！
@Xeo 不是特别的。我可以忍受为该文件禁用所有警告。它不必具有特定的包含模式。我怀疑我提出问题的方式有点不幸。
你用的是什么编译器？（抑制警告的方法通常因编译器而异。）

标签： c++ suppress-warnings

【解决方案1】：

使用 GCC 时，您可以使用 -isystem 标志而不是 -I 标志来禁用来自该位置的警告。

所以如果你目前正在使用

gcc -Iparent/path/of/bar …

使用

gcc -isystem parent/path/of/bar …

相反。不幸的是，这不是一个特别细粒度的控制。我不知道更有针对性的机制。

【讨论】：

在clang中有--system-header-prefix=选项，见clang.llvm.org/docs/…

【解决方案2】：

更好的 GCC 解决方案：使用 #pragma。

#pragma GCC diagnostic push 
#pragma GCC diagnostic ignored "-W<evil-option>"
#include <evil_file>
#pragma GCC diagnostic pop

例如：

#pragma GCC diagnostic push 
#pragma GCC diagnostic ignored "-Wunused-local-typedefs"
#include <QtXmlPatterns>
#pragma GCC diagnostic pop

【讨论】：

这不是我想要的。我寻求一种方法来禁用所有以“Qt”开头的文件的警告（以保持您的示例。不仅针对单个命名文件。我们已经使用诊断推送/弹出，但不幸的是，这不能对文件名进行通配符匹配据我们所知。
对不起，我误会了。 AFAIK，您只有两个选择：创建一个包含所有有问题的头文件的头文件，包装在 #pragma diagnostic 中并首先包含它（并依靠多包含保护来处理文件一次）。或者，使用 -isystem 将标头视为系统标头。我不认为有一种方法可以基于包含路径（超出 isystem 的行为）定义自定义诊断规则。我一直使用“创建一个“include_all_bar.h”文件”方法来解决这个问题。
不得不说，虽然这个答案不是最高票，但我确实认为它非常有用。虽然它不完全符合原始问题（路径/前缀中的所有库），但它确实提供了一种方法来选择性地排除给定标题集的一些警告。 ?

【解决方案3】：

当我使用g++ 时，我有第三方标头会生成大量警告，而我通常默认为-Wall -Wextra & co。我倾向于将它们分组在单独的包含中，指定 system_header #pragma。

[...] GCC 对系统头文件中的代码进行特殊处理。除了#warning 生成的警告（参见诊断）之外，所有警告都会在 GCC 处理系统标头时被抑制。系统标头中定义的宏在扩展时不受一些警告的影响。当我们发现由于系统标头中定义的宏中的代码导致警告产生大量误报时，这种豁免权是临时授予的。

[...]

还有一个指令，#pragma GCC system_header，它告诉 GCC 将当前包含文件的其余部分视为系统头，无论它是在哪里找到的。文件中#pragma 之前的代码不会受到影响。 #pragma GCC system_header 在主源文件中无效。

与-isystem 相比，我更喜欢这个解决方案，因为它更细粒度，我可以将它直接放在源代码中，而不会过多地使用命令行参数和包含目录。

可怕的根库示例：

#ifndef ROOTHEADERS_HPP_INCLUDED
#define ROOTHEADERS_HPP_INCLUDED
#ifdef __GNUC__
// Avoid tons of warnings with root code
#pragma GCC system_header
#endif
#include "TH1F.h"
#include "TApplication.h"
#include "TGraph.h"
#include "TGraph2D.h"
#include "TCanvas.h"
#endif

【讨论】：

哦，很好。 +1 … 不幸的是，这些文件往往出现在其他包含文件之前，并且应用编译指示似乎会影响文件的其余部分，即所有以下包含。
@Konrad Rudolph：你确定吗？不是只有一个包含及其子包含吗？
@Green 是的，我就是这个意思。尽管如此，这要求我要么将所有有问题的包含放在包含列表的末尾（正如我所说的那样，这通常是不可取的甚至是不可能的）或将所有有问题的包含放入单独的标题中，然后您将其包括在内。在大型协作项目中，这也不是一个完美的选择。
@Konrad：第二种解决方案是我采用的。

【解决方案4】：

我想最简单的解决方案是编写一个简单的脚本，该脚本将根据文件名和警告类型调用编译器、编译并去除不需要的输出。您可以为每个编译器使用不同的脚本。

只需更新您的 makefile 以使用此脚本，而不是直接调用编译器。

【讨论】：

【解决方案5】：

从重复的thread 复制我的答案。

您可以使用抑制编译指示。

GCC 和 VC++ 编译器支持此功能，如下所示：

#pragma warning(push)
#pragma warning(disable : 4244)
#pragma warning(disable : 4127)
#pragma warning(disable : 4512)
#include <boost/python.hpp>
#pragma warning(pop)

以下是详细规格：

VC++
GCC

【讨论】：