检测必要的#includes [英] detect necessary #includes
问题描述
在项目开发几周后，可能会有很多
" #include"在以前添加的源文件中，但现在不需要
。是否有任何工具可以找出那些#includes
并告诉我删除它们是否安全？手工工作非常耗时。
谢谢。
-
woody
after some weeks of development of a project, there likely are many
"#include" in source files which was added before but are now
unnecessary. is there any tool which can find out those "#include"s
and tell me it''s safe to remove them? manual work is so time consuming.
thanks.
-
woody
推荐答案
Steven Woody写道：
Steven Woody wrote:
经过几个星期的项目开发，可能会有很多
#include在之前添加但现在没有必要的源文件中。是否有任何工具可以找出那些#includes
并告诉我删除它们是否安全？手动工作非常耗时。
after some weeks of development of a project, there likely are many
"#include" in source files which was added before but are now
unnecessary. is there any tool which can find out those "#include"s
and tell me it''s safe to remove them? manual work is so time consuming.
只有标准文档或其他API文档才能真正告诉您是否安全删除一个#include。
考虑如果有些文档说明会发生什么：
" foo（）在foo.h中可用，和bar（）在bar.h中可用"
然后假设foo.h和bar.h都包含这个：
#include< foobar.h>
和foobar.h包含foo（）和bar（）的原型。
现在让我们假设您的代码同时使用foo（）和bar（），并且您通过反复试验确认
，确定您只能包含
foo.h，你删除了bar.h的include。它现在会编译OK
，但是当你使用的
foobar库改变它的实现以便foo（）的原型时会发生什么呢？
真的在foo.h中，而bar（）的原型真的在bar.h中吗？你将会为自己创造一个可怕的混乱，因为你的#includes
取决于.h文件的怪癖，这些都不保证
而不是取决于文档所保证的内容。
更重要的是，如何在头文件中看到任何自动程序
告诉哪个头文件是
文档保证可以使用的？
我想在某些有限的情况下可能会写这样的
a工具，例如，如果没有.h文件，则每个都包含另一个.h文件，但
，这不是大多数.h文件通常工作的方式......
- Logan
Only a standards document or other API documentation can really tell
you whether it''s safe to remove a #include.
Consider what happens if some documentation says this:
"foo() is available in foo.h, and bar() is available in bar.h".
Then suppose that foo.h and bar.h both contain this:
#include <foobar.h>
and that foobar.h contains the prototypes for both foo() and bar().
Now let''s suppose that your code uses both foo() and bar(), and you,
by trial and error, determine you can get away by only including
foo.h, and you remove the include for bar.h. It will compile OK
right now, but what happens later on when the foobar library that
you''re using changes its implementation so that foo()''s prototype
is really in foo.h and bar()''s prototype is really in bar.h? You
will have created for yourself a horrible mess because your #includes
are depending on quirks of the .h files which aren''t guaranteed
rather than depending on what is guaranteed by the documentation.
More to the point, how can any automated program that just looks
at header files tell which header files are the ones that the
documentation guarantees will work?
I suppose it might be possible in some limited cases to write such
a tool, such as if no .h file every includes another .h file, but
that''s not how most .h files usually work...
- Logan
Logan Shaw写道：
Logan Shaw wrote:
Steven Woody写道：
Steven Woody wrote:
经过几个星期的项目开发，可能会有很多
#include。在之前添加但现在没有必要的源文件中。是否有任何工具可以找出那些#includes
并告诉我删除它们是否安全？手动工作非常耗时。
after some weeks of development of a project, there likely are many
"#include" in source files which was added before but are now
unnecessary. is there any tool which can find out those "#include"s
and tell me it''s safe to remove them? manual work is so time consuming.
只有标准文档或其他API文档才能真正告诉你，删除#include是否安全。
考虑如果有些文档说明会发生什么：foo.h中有foo（），bar.h中有bar（）。
然后假设foo.h和bar.h都包含这个：
#include< foobar.h>
并且foobar.h包含原型对于foo（）和bar（）。
现在让我们假设您的代码同时使用foo（）和bar（），并且您通过反复试验确定了
你可以通过只包括
foo.h逃脱，并删除bar.h的include。它现在可以编译好了，但是当你正在使用的foobar库改变它的实现以便foo（）的原型确实在foo中时会发生什么呢？ .h和bar（）的原型真的在bar.h吗？你会为自己创造一个可怕的混乱，因为你的#includes
依赖于.h文件的怪癖而不是保证
而不是取决于文档所保证的内容。
更重要的是，任何看起来像头文件的自动程序怎么能告诉哪些头文件是
文档保证会起作用的呢？
我想在某些有限的情况下可能会编写这样的工具，例如，如果没有.h文件，每个都包含另一个.h文件，但是
那不是怎么回事大多数.h文件通常都有效...
- Logan
Only a standards document or other API documentation can really tell
you whether it''s safe to remove a #include.
Consider what happens if some documentation says this:
"foo() is available in foo.h, and bar() is available in bar.h".
Then suppose that foo.h and bar.h both contain this:
#include <foobar.h>
and that foobar.h contains the prototypes for both foo() and bar().
Now let''s suppose that your code uses both foo() and bar(), and you,
by trial and error, determine you can get away by only including
foo.h, and you remove the include for bar.h. It will compile OK
right now, but what happens later on when the foobar library that
you''re using changes its implementation so that foo()''s prototype
is really in foo.h and bar()''s prototype is really in bar.h? You
will have created for yourself a horrible mess because your #includes
are depending on quirks of the .h files which aren''t guaranteed
rather than depending on what is guaranteed by the documentation.
More to the point, how can any automated program that just looks
at header files tell which header files are the ones that the
documentation guarantees will work?
I suppose it might be possible in some limited cases to write such
a tool, such as if no .h file every includes another .h file, but
that''s not how most .h files usually work...
- Logan
i我不会删除任何标准或系统范围#includes，我是
将删除那些包含我自己标题的#includes。
i am not going to remove any standard or system wide #includes, i am
going to remove those #includes which include my own headers.
Steven Woody写道：
Steven Woody wrote:
经过几个星期的项目开发，可能会有很多
"＃包括"在之前添加但现在没有必要的源文件中。是否有任何工具可以找出那些#includes
并告诉我删除它们是否安全？手工工作非常耗时。
谢谢。
-
woody
after some weeks of development of a project, there likely are many
"#include" in source files which was added before but are now
unnecessary. is there any tool which can find out those "#include"s
and tell me it''s safe to remove them? manual work is so time consuming.
thanks.
-
woody
PC-lint（ www.gimpel.com ）那样做，IIRC。
Bj？rn
PC-lint(www.gimpel.com) does that, IIRC.
Bj?rn
这篇关于检测必要的#includes的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
