我经常发现文件的头部分总是变得越来越大，但它从来没有变小过。在源文件的整个生命周期中，类可能会被移动和重构，并且很可能有相当多的#include不需要存在。保留它们只会延长编译时间，并增加不必要的编译依赖关系。试图找出哪些仍然需要是相当乏味的。
是否有某种工具可以检测多余的#include指令，并建议哪些我可以安全地删除? 棉绒会这样吗?
当前回答
这里有一个简单的暴力方法来识别多余的头包含。它并不完美，但消除了“明显的”不必要的包含。清除这些代码对清理代码大有帮助。
这些脚本可以直接在GitHub上访问。
其他回答
也许有点晚了，但我曾经找到一个WebKit perl脚本，它做的正是你想要的。我相信它需要一些调整(我不太精通perl)，但它应该能做到:
http://trac.webkit.org/browser/branches/old/safari-3-2-branch/WebKitTools/Scripts/find-extra-includes
(这是一个旧的分支，因为trunk不再有文件了)
Clangd现在正在为你做这件事。clang-tidy可能很快也能做到这一点。
我从来没有找到一个成熟的工具来完成你的要求。我使用过的最接近的工具是IncludeManager，它将头包含树图形化，以便您可以直观地发现只包含在一个文件中的头和循环头包含之类的内容。
这不是自动的，但是doxygen会为#included文件生成依赖关系图。你必须从视觉上看它们，但它们对于了解什么在使用什么是非常有用的。
您可以编写一个快速脚本，删除单个#include指令，编译项目，并在没有发生编译错误的情况下记录#include中的名称和它被删除的文件。
让它在晚上运行，第二天你就会有一个100%正确的可以删除的包含文件列表。
有时候蛮力很管用:-)
编辑:有时它不会:-)。下面是一些来自评论的信息:
Sometimes you can remove two header files separately, but not both together. A solution is to remove the header files during the run and not bring them back. This will find a list of files you can safely remove, although there might a solution with more files to remove which this algorithm won't find. (it's a greedy search over the space of include files to remove. It will only find a local maximum) There may be subtle changes in behavior if you have some macros redefined differently depending on some #ifdefs. I think these are very rare cases, and the Unit Tests which are part of the build should catch these changes.
