我应该如何检测大型C ++项目中不必要的#include文件?

我正在Visual Studio 2008中处理一个大的C ++项目,并且有很多文件包含不必要的#include指令。 有时#include只是工件,所有东西都可以正确的编译,而在其他情况下,类可以被声明,#include可以被移动到.cpp文件中。 有没有什么好的工具来检测这两种情况?

虽然它不会显示不需要的包含文件,Visual Studio有一个设置/showIncludes (右键单击.cpp文件, Properties->C/C++->Advanced ),将在编译时输出包含所有文件的树。 这可以帮助识别不需要包含的文件。

你也可以看一下pimpl的习惯用法,让你可以用较less的头文件依赖关系来获取,以便更容易地看到你可以删除的文件。

PC Lint在这方面工作的很好,也为你find了各种其他愚蠢的问题。 它具有可用于在Visual Studio中创build外部工具的命令行选项,但是我发现Visual Lint插件更易于使用。 即使免费版本的视觉林特帮助。 但给PC-Lint一枪。 configuration它,所以它不会给你太多的警告需要一点时间,但你会惊讶于它的结果。

!!免责声明! 我使用商业静态分析工具(而不是PC Lint)。 !!免责声明!

简单的非parsing方法有几个问题:

1)过载集合:

重载的函数有可能声明来自不同的文件。 这可能是删除一个头文件导致select不同的重载,而不是编译错误! 结果将是语义上的一个沉默的变化,事后可能很难find。

2)模板专业化:

与重载示例类似,如果您对模板有部分或显式的特化,则希望在使用模板时全部可见。 主模板的专业化可能在不同的头文件中。 使用特化除去标题不会导致编译错误,但是如果已经select了特化,可能会导致未定义的行为。 (请参阅: C ++函数的模板特化的可见性 )

正如'msalters'指出的那样,对代码进行全面分析也可以分析类的使用情况。 通过检查一个类是如何通过一个特定的文件path来使用的,这个类的定义(以及它的所有依赖关系)可以被完全移除,或者至less被移动到更接近于包含主要源树。

有一个新的基于铿锵的工具, 包括你用什么 ,目的是做到这一点。

我不知道有没有这样的工具,而且我曾经想过写一个,但事实certificate,这是一个难以解决的问题。

说你的源文件包括ah和bh; 啊包含#define USE_FEATURE_X和bh使用#ifdef USE_FEATURE_X 。 如果#include "ah"被注释掉了,你的文件仍然可以编译,但是可能不会达到你所期望的。 以编程方式检测这个并不重要。

无论这个工具是否需要知道你的构build环境。 如果啊看起来像:

 #if defined( WINNT ) #define USE_FEATURE_X #endif 

那么USE_FEATURE_X只有在WINNT被定义的情况下才被定义,所以这个工具需要知道编译器本身产生了哪些指令,哪些指令是在编译命令中指定的,而不是在头文件中指定的。

像Timmermans一样,我不熟悉任何工具。 但是我知道编写Perl(或者Python)脚本的程序员尝试注释掉每个包含的行,然后编译每个文件。


现在看来,Eric Raymond 有一个这样的工具 。

谷歌的cpplint.py有一个“包括你使用”的规则(其中包括许多其他),但据我所知,没有“ 包括你使用的东西”。 即使如此,它可能是有用的。

如果您对这个主题感兴趣,您可能需要查看Lakos的大型C ++软件devise 。 这有点过时了,但进入了很多“物理devise”问题,如find需要包含的标题的绝对最小值。 我还没有真正看到其他地方讨论过这种事情。

如果你的头文件通常以

 #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文件的名字,这会让你至less知道哪个cpp文件导致头被多次带入。

给包括经理一个尝试。 它在Visual Studio中轻松集成,可视化您的包含path,帮助您find不必要的东西。 它在内部使用Graphviz,但还有很多很酷的function。 虽然它是一个商业产品,它的价格非常低。

您可以使用C / C ++包含文件相关性监视器来构build一个包含graphics,并且可以直观地查找不需要的内容。

PC-Lint的确可以做到这一点。 一个简单的方法是将其configuration为只检测未使用的包含文件,并忽略所有其他问题。 这很简单 – 只启用消息766(“Header file not in module”),只需在命令行中包含选项-w0 + e766。

相同的方法也可以用于相关消息,如964(“模块中不直接使用的头文件”)和966(“模块中未使用的间接包含的头文件”)。

FWIW我在上周的博客文章中更详细地写了这篇文章: http: //www.riverblade.co.uk/blog.php?archive=2008_09_01_archive.xml#3575027665614976318。

如果您正在寻找删除不必要的#include文件以减less构build时间,那么花时间和金钱可能会更好地使用cl.exe / MP , make -j , Xoreax IncrediBuild ,distcc / icecream等并行化您的构build过程。

当然,如果你已经有了一个并行的构build过程,并且你还在努力加速它,那么通过一切手段来清理你的#include指令,并删除那些不必要的依赖关系。

从每个包含文件开始,并确保每个包含文件只包含编译自身所需的内容。 任何包含文件,然后丢失的C + +文件,可以被添加到C + +文件本身。

对于每个包含和源文件,每个注释包含一个文件,并查看它是否编译。

按字母顺序对包含文件进行sorting也是一个好主意,在不可能的地方添加注释。

添加下面的一个或两个#defines将排除经常不必要的头文件,并且可能大大提高编译时间,特别是如果不使用Windows API函数的代码。

 #define WIN32_LEAN_AND_MEAN #define VC_EXTRALEAN 

请参阅http://support.microsoft.com/kb/166474

如果您还没有使用预编译头文件来包含您不会更改的所有内容(平台头文件,外部SDK头文件或静态已完成的项目文件),那么构build时间将会产生巨大差异。

http://msdn.microsoft.com/en-us/library/szfdksca(VS.71).aspx

另外,虽然对于你的项目来说可能为时过晚,但是把你的项目分成几个部分,而不是把所有的本地头部包含到一个大主标题中,这是一个很好的做法,尽pipe这需要一些额外的工作。

如果你使用Eclipse CDT,你可以试试http://includator.com来优化你的包含结构。 然而,对于VC ++的预定义包含而言,includator可能还不够了解,build立CDT使用VC ++与正确的包含尚未内置到CDT中。

最新的Jetbrains IDE CLion会自动显示(灰色)当前文件中未使用的包含。

还可以从IDE获得所有未使用的包含(以及函数,方法等)的列表。

一些现有的答案表明这很难。 确实如此,因为您需要一个完整的编译器来检测前向声明是合适的情况。 你不能不知道符号是什么意思,就不能parsingC ++。 语法太简单了。 您必须知道某个名称是否指定了一个类(可以是前向声明的)或variables(不能)。 另外,您需要具有名称空间感知function。

也许有点晚,但我曾经find一个WebKit perl脚本,只是做你想要的。 它需要适应我相信(我不熟悉perl),但它应该做的伎俩:

http://trac.webkit.org/browser/branches/old/safari-3-2-branch/WebKitTools/Scripts/find-extra-includes

(这是一个旧的分支,因为主干没有该文件了)

如果有一个你认为不再需要的头文件(比如string.h),你可以注释掉include,然后把它放在下面的所有内容中:

 #ifdef _STRING_H_ # error string.h is included indirectly #endif 

当然你的接口头文件可能会使用一个不同的#define约定logging它们包含在CPP内存中。 还是没有约定,在这种情况下,这种方法将无法正常工作。

然后重build。 有三种可能性:

  • 它build立好了。 string.h不是编译关键字,可以删除它的包含。

  • #恐怖旅行。 string.g被间接包含在内你还是不知道是否需要string.h。 如果需要,你应该直接#包括它(见下文)。

  • 你得到一些其他的编译错误。 string.h是需要的,并没有被间接包含,所以包含是正确的开始。

注意,当你的.h或者.c直接使用另一个.h或者.c时,根据间接包含,几乎可以肯定是一个错误:只要你使用的其他头文件需要它,你的代码将只需要这个头文件,这可能不是你的意思。

其他答案中提到的关于修改行为的头文件中提到的注意事项,以及声明导致构build失败的事情也适用于此处。