我经常发现文件的头部分总是变得越来越大，但它从来没有变小过。在源文件的整个生命周期中，类可能会被移动和重构，并且很可能有相当多的#include不需要存在。保留它们只会延长编译时间，并增加不必要的编译依赖关系。试图找出哪些仍然需要是相当乏味的。
是否有某种工具可以检测多余的#include指令，并建议哪些我可以安全地删除? 棉绒会这样吗?
当前回答
很抱歉(再次)在这里发帖，人们通常不扩展评论。
检查我对crashmstr的评论，FlexeLint / PC-Lint会为你做这件事。信息信息766号。我的手册(8.0版)的11.8.1节讨论了这个问题。
另外，这一点很重要，不断迭代，直到消息消失。换句话说，在删除了不需要的头文件后，重新运行lint，一旦删除了一些不需要的头文件，更多的头文件可能已经成为“不需要的”。(这可能听起来很傻，慢慢读并分析它，这是有道理的。)
其他回答
很抱歉(再次)在这里发帖，人们通常不扩展评论。
检查我对crashmstr的评论，FlexeLint / PC-Lint会为你做这件事。信息信息766号。我的手册(8.0版)的11.8.1节讨论了这个问题。
另外，这一点很重要，不断迭代，直到消息消失。换句话说，在删除了不需要的头文件后，重新运行lint，一旦删除了一些不需要的头文件，更多的头文件可能已经成为“不需要的”。(这可能听起来很傻，慢慢读并分析它，这是有道理的。)
我认为PCLint可以做到这一点，但我已经有几年没有研究它了。你可以去看看。
我看了这个博客，作者谈到了一些关于配置PCLint以查找未使用的包含的内容。也许值得一看。
这里有一个简单的暴力方法来识别多余的头包含。它并不完美，但消除了“明显的”不必要的包含。清除这些代码对清理代码大有帮助。
这些脚本可以直接在GitHub上访问。
CScout重构浏览器可以检测C(不幸的是不是c++)代码中多余的include指令。你可以在这篇期刊文章中找到它如何工作的描述。
我从来没有找到一个成熟的工具来完成你的要求。我使用过的最接近的工具是IncludeManager，它将头包含树图形化，以便您可以直观地发现只包含在一个文件中的头和循环头包含之类的内容。
