我正在 Visual Studio 2008 中处理一个大型 C++ 项目，并且有很多文件包含不必要的 #include 指令。有时#includes 只是工件，删除它们后一切都可以正常编译，而在其他情况下，可以向前声明类并且可以将#include 移动到.cpp 文件中。有什么好的工具可以检测这两种情况吗？
【问题讨论】：
标签： c++ visual-studio-2008 include header dependencies
有一个新的基于 Clang 的工具，include-what-you-use，旨在做到这一点。
【讨论】：
虽然它不会显示不需要的包含文件，但 Visual Studio 有一个设置 /showIncludes（右键单击 .cpp 文件，Properties->C/C++->Advanced），它将在编译时输出所有包含文件的树。这有助于识别不需要包含的文件。
您还可以查看 pimpl idiom 以减少头文件依赖项，从而更轻松地查看可以删除的内容。
【讨论】：
最新的 Jetbrains IDE CLion 会自动显示（灰色）当前文件中未使用的包含。
还可以从 IDE 中获取所有未使用的包含（以及函数、方法等）的列表。
【讨论】：
如果您认为不再需要某个特定标题（例如 string.h)，你可以注释掉包含然后把它放在所有下面 包括：
#ifdef _STRING_H_
# error string.h is included indirectly
#endif
当然，您的接口标头可能使用不同的#define 约定 记录它们在 CPP 内存中的包含情况。或者没有约定，在这种情况下 这种方法行不通。
然后重建。有三种可能：
构建正常。 string.h 不是编译关键的，并且包含它 可以删除。
#error 跳闸。 string.g 以某种方式间接包含在内 您仍然不知道是否需要 string.h。如果需要，您 应该直接#include它（见下文）。
您会遇到一些其他编译错误。 string.h 是需要的，但不是 间接包含，因此包含一开始是正确的。
请注意，当您的 .h 或 .c 直接使用时，取决于间接包含 另一个 .h 几乎可以肯定是一个错误：您实际上是在承诺您的 只要您正在使用的其他标头，代码就只需要该标头 需要它，这可能不是你的意思。
其他答案中提到的关于修改行为的标头的警告 而声明导致构建失败的东西也适用于此。
【讨论】：
和 Timmermans 一样，我不熟悉任何用于此目的的工具。但我认识的程序员写了一个 Perl（或 Python）脚本来尝试一次注释掉每个包含行，然后编译每个文件。
现在看来，Eric Raymond has a tool for this。
Google 的 cpplint.py 有一个“包括您使用的内容”规则（以及许多其他规则），但据我所知，没有“包括仅您使用的内容”。即便如此，它还是很有用的。
【讨论】：
如果您使用 Eclipse CDT，您可以尝试使用http://includator.com 来优化您的包含结构。但是，Includator 可能对 VC++ 的预定义包含不够了解，并且设置 CDT 以使用具有正确包含的 VC++ 尚未内置到 CDT 中。
【讨论】：
也许有点晚了，但我曾经发现一个 WebKit perl 脚本可以满足您的需求。我相信它需要一些调整（我不太精通 perl），但它应该可以解决问题：
（这是一个旧分支，因为主干不再有文件）
【讨论】：
您可以使用C/C++ Include File Dependencies Watcher 构建包含图，并直观地查找不需要的包含。
【讨论】：
试试Include Manager。它可以轻松集成到 Visual Studio 中，并可视化您的包含路径，从而帮助您找到不必要的东西。 它在内部使用 Graphviz，但还有更多很酷的功能。虽然它是商业产品，但价格非常低。
【讨论】：
如果您对该主题感兴趣，您可能需要查看 Lakos 的 Large Scale C++ Software Design。它有点过时了，但涉及到许多“物理设计”问题，比如找到需要包含的绝对最小的标题。我还没有在其他任何地方真正看到过这种讨论。
【讨论】：
PC-Lint 确实可以做到这一点。一种简单的方法是将其配置为仅检测未使用的包含文件并忽略所有其他问题。这非常简单 - 只启用消息 766（“模块中未使用的头文件”），只需在命令行中包含选项 -w0 +e766。
同样的方法也可以用于相关消息，例如 964（“模块中未直接使用的头文件”）和 966（“模块中未使用的间接包含的头文件”）。
FWIW 我上周在http://www.riverblade.co.uk/blog.php?archive=2008_09_01_archive.xml#3575027665614976318 的一篇博文中更详细地介绍了这一点。
【讨论】：
如果你的头文件一般以
开头#ifndef __SOMEHEADER_H__
#define __SOMEHEADER_H__
// header contents
#endif
（而不是使用 #pragma 一次）您可以将其更改为：
#ifndef __SOMEHEADER_H__
#define __SOMEHEADER_H__
// header contents
#else
#pragma message("Someheader.h superfluously included")
#endif
并且由于编译器会输出正在编译的 cpp 文件的名称，这至少会让您知道哪个 cpp 文件导致头被多次引入。
【讨论】：
A.h 和B.h 都依赖于C.h 并且你包括A.h 和B.h 时，因为你需要两者，你将 包括C.h 两次，但是没关系，因为编译器会第二次跳过它，如果你不这样做，你必须记住总是在 A.h 或 B.h 之前包含 C.h ，最终导致更多无用的包含。
从每个包含文件开始，并确保每个包含文件只包含编译自身所需的内容。 C++ 文件中缺少的任何包含文件都可以添加到 C++ 文件本身中。
对于每个包含和源文件，一次注释掉每个包含文件，看看它是否可以编译。
按字母顺序对包含文件进行排序也是一个好主意，如果无法做到这一点，请添加注释。
【讨论】：
如果您还没有使用预编译头文件来包含您不会更改的所有内容（平台头文件、外部 SDK 头文件或项目中已完成的静态部分），那么构建时间会产生巨大差异.
http://msdn.microsoft.com/en-us/library/szfdksca(VS.71).aspx
此外，尽管对您的项目来说可能为时已晚，但将项目组织成多个部分并且不将所有本地标题集中到一个大的主标题中是一种很好的做法，尽管这需要一些额外的工作。
【讨论】：
！！免责声明！！我从事商业静态分析工具（不是 PC Lint）。 !!免责声明!!
简单的非解析方法存在几个问题：
1) 重载集：
重载函数的声明可能来自不同的文件。可能是删除一个头文件会导致选择不同的重载而不是编译错误！结果将是语义上的静默变化，之后可能很难追踪。
2) 模板特化：
与重载示例类似，如果您有模板的部分或显式特化，您希望在使用模板时它们全部可见。可能是主模板的特化位于不同的头文件中。使用特化删除标头不会导致编译错误，但如果选择了特化，则可能导致未定义的行为。 （见：Visibility of template specialization of C++ function）
正如“msalters”所指出的，对代码进行全面分析还可以分析类的使用情况。通过检查如何通过特定的文件路径使用类，可以完全删除类的定义（以及因此它的所有依赖项），或者至少将其移动到更接近包含中主要源的级别树。
【讨论】：
一些现有的答案表明这很难。确实如此，因为您需要一个完整的编译器来检测适合前向声明的情况。如果不知道符号的含义，就无法解析 C++；语法太模棱两可了。您必须知道某个名称是命名一个类（可以向前声明）还是一个变量（不能）。此外，您需要了解命名空间。
【讨论】：
如果您希望删除不必要的 #include 文件以减少构建时间，您最好将时间和金钱花在使用 cl.exe /MP、make -j、Xoreax IncrediBuild、distcc/@987654324 并行构建过程上@等
当然，如果您已经有一个并行构建过程并且您仍在尝试加快它，那么请务必清理您的 #include 指令并删除那些不必要的依赖项。
【讨论】：
添加以下一项或两项#defines 将排除通常不必要的头文件和 可能会大大改善 编译时间，尤其是在不使用 Windows API 函数的代码时。
#define WIN32_LEAN_AND_MEAN
#define VC_EXTRALEAN
【讨论】：
PC Lint 可以很好地解决这个问题，它还可以为您找到各种其他愚蠢的问题。它具有可用于在 Visual Studio 中创建外部工具的命令行选项，但我发现 Visual Lint 插件更易于使用。甚至 Visual Lint 的免费版本也有帮助。但是给 PC-Lint 一个机会。配置它以便它不会给你太多警告需要一些时间，但你会惊讶于它的出现。
【讨论】：
我不知道有这样的工具，之前也想过写一个，结果发现这是一个很难解决的问题。
假设你的源文件包含 a.h 和 b.h； a.h 包含#define USE_FEATURE_X，b.h 使用#ifdef USE_FEATURE_X。如果#include "a.h" 被注释掉，您的文件可能仍然可以编译，但可能无法达到您的预期。 以编程方式检测这一点并非易事。
无论使用什么工具，这都需要了解您的构建环境。如果 a.h 看起来像：
#if defined( WINNT )
#define USE_FEATURE_X
#endif
然后USE_FEATURE_X 仅在定义WINNT 时才被定义，因此该工具需要知道编译器本身生成了哪些指令，以及哪些指令是在编译命令中而不是在头文件中指定的。
【讨论】：