Steven said:
hi,
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.
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