正在评论#include一种安全的方式，看看它是否不需要？

Question

我喜欢保持文件干净，所以我更愿意拿出我不需要的文件。最近我一直在评论包含，看看它是否在没有警告的情况下进行编译（-Wall -Wextra -pedantic，减去几个非常具体的内容）。我想如果它没有警告就编译我不需要它。

这实际上是一种安全的方法来检查是否需要包含或者是否会引入UB或其他问题？是否有任何具体的警告我需要确保能够发现潜在的问题？

<子> n.b。我实际上正在使用Objective C和clang，所以对这些特定的东西表示赞赏，但考虑到Objective C的灵活性，我认为如果有任何问题，它将是一般的C事物。当然，C中的任何问题都会影响目标C.

Answer 1

原则上，是的。

例外情况是两个标题以某种隐藏方式交互。说，如果你：

• 包含两个不同的标题，它们以不同的方式定义相同的符号，
• 这两个定义在语法上都是有效且类型合适的，
• 但是一个定义很好，另一个定义在运行时破坏了你的程序。

希望您的头文件不是那样的结构。这有点不太可能，但并非不可思议。

如果我有好的（单位）测试，我会更自在地做这件事。

Answer 2

通常只是注释掉包含标题是安全的，这意味着：如果需要标题，那么删除它时会出现编译错误，并且（通常）如果不需要标题，代码仍然可以正常编译

如果没有检查标题以查看它添加的内容，则不应该这样做，因为标题只提供可选的#define（或#undef）（可能会改变但不会中断）的（非常典型）可能性。程序编译的方式。

唯一可行的方法是在没有标题的情况下构建代码（如果它能够在第一时间构建）并运行适当的测试方案以确保其行为没有改变。

Answer 3

一般来说，没有。很容易引入无声的变化。

假设header.h定义了一些像

这样的宏

#define WITH_FEATURE_FOO

包含header.h的C文件测试宏

#ifdef WITH_FEATURE_FOO
     do_this();
#else
     do_that();
#endif 

您的文件编译干净，所有警告都启用，包含或不包含header.h，但结果表现不同。获得确定答案的唯一方法是分析标头定义/声明的标识符，并查看它们中是否至少有一个出现在预处理的C文件中。

这样做的一个工具是来自Gimpel的FlexeLint。我不会因为这样说而得到报酬，即使他们应该:-)如果你想避免花大钱，我一直采取的方法是将C文件编译成带有和没有标题的目标文件，如果两者都成功检查相同的目标文件。如果它们是相同的，则您不需要标题 （但请注意#ifdef选项启用的包含在-DWITH_FEATURE_FOO中的include指令。

Answer 4

没有。除了在其他答案中已经提到的原因之外，可能需要标题而另一个标题间接包含它。如果您删除#include，则不会看到错误，但其他平台上可能存在错误。