Re: Tool to determine which headers are needed/not_needed?

robertwessel2@xxxxxxxxx wrote, On 11/09/08 02:48:
On Sep 10, 7:09 pm, CBFalconer <cbfalco...@xxxxxxxxx> wrote:
C_guy wrote:

Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? This would be helpful in removing header
inclusions that are redundant and/or unnecessary.
Use your editor. Comment out a #include statement. Recompile. If
no errors appear, that statement can go. If errors appear, remove
the comment. Repeat.


Surely that's too simplistic - consider a header containing:

#undef FOO
#define FOO 17

Assuming a prior definition of FOO (to something other than 17), one
could easily see the compilation succeed, yet no longer be producing
the correct program).

Or a header that contains:

int a=1;

And everywhere else (possibly in the same compilation unit, if needed)
there's:

int a;

Many other potential problems exist

A far more likely potential problem in my opinion is if the header contains:
double foo(...)

Then with the default options on a lot of compilers (or with C89 conformance added to the defaults) the compiler will *not* complain, it will just silently compiler the code with what is now undefined behaviour which may or may not work. If foo currently returns an int it is even worse, because then (if the parameters are not a problem) it *will* work until foo() the return type of foo is changed.

Which is not to say that sort of things is good programming practice
(and frankly most dependencies like that probably reflect poor
design), but we've all seen really bizarre stuff in headers, no?

You don't need bizarre stuff in the header for commenting it out to silently cause problems. Simple good practice can do it.

The OP would be well advised to ensure that the compiler is told to warn about functions being called without a prototype in scope, and as much else as possible. This will help catch problems where a header is *not* included (directly or indirectly) but is needed. How to do this (and if it is possible) is compiler dependant and so should be asked on a group dedicated to the compiler.
--
Flash Gordon
.

Relevant Pages

  • Re: Parameter Name Warning?
    ... there is more to those names than just what the compiler does with them. ... You know only what you get in the header. ... correct for me in the watch window. ... >> int main ...
    (microsoft.public.vc.language)
  • Re: Header Files and Interfaces Yet Again
    ... compiler is not allowed to read them. ... illustrate the difference of header file and fake header. ... fake headers can not serve as sufficient information to the ... > something but it appears to me the Standard Library is not designed ...
    (comp.lang.cpp)
  • Re: Cpp Considered Harmful
    ... >> I will observe that many Java IDEs do this rather successfully. ... > Look, if a tool author is willing to fully parse the underlying language, ... > compiler version. ... mentions a header file is in the C compatability appendix. ...
    (comp.lang.cpp)
  • Re: Parameter Name Warning?
    ... the names on the declarations do not matter, it should perhaps give a warning regarding different names being used. ... > there is more to those names than just what the compiler does with them. ... > You know only what you get in the header. ... >>> int main ...
    (microsoft.public.vc.language)
  • Re: Error in compliling AODB _ConnectionPtr
    ... The compiler ignores ALL input ... because it may affect the definitions in that header. ... >> int main ... I had it wrong at first anf the complier never complained. ...
    (microsoft.public.vc.atl)