I know PC-Lint can tell you about headers which are included but not used. Are there any other tools that can do this, preferably on linux?
We have a large codebase that through the last 15 years has seen plenty of functionality move around, but rarely do the leftover #include directives get removed when functionality moves from one implementation file to another, leaving us with a pretty good mess by this point. I can obviously do the painstaking thing of removing all the #include directives and letting the compiler tell me which ones to reinclude, but I'd rather solve the problem in reverse - find the unused ones - rather than rebuilding a list of used ones.
To check if an header file has been included or not in a C or C++ code, we need to check if the macro defined in the header file is being defined in the client code. Standard header files like math. h have their own unique macro (like _MATH_H ) which we need to check. Consider this example of checking if math.
The open and creat functions are declared in the header file fcntl. h , while close is declared in unistd. h .
The angle brackets (<>) cause the preprocessor to search for the header file in the standard place for header files on your system, usually the /usr/include directory.
Your #include s should be of header files, and each file (source or header) should #include the header files it needs. Header files should #include the minimum header files necessary, and source files should also, though it's not as important for source files.
DISCLAIMER: My day job is working for a company that develops static analysis tools.
I would be surprised if most (if not all) static analysis tools did not have some form of header usage check. You could use this wikipedia page to get a list of available tools and then email the companies to ask them.
Some points you might consider when you're evaluating a tool:
For function overloads, you want all headers containing overloads to be visible, not just the header that contains the function that was selected by overload resolution:
// f1.h void foo (char); // f2.h void foo (int); // bar.cc #include "f1.h" #include "f2.h" int main () { foo (0); // Calls 'foo(int)' but all functions were in overload set }
If you take the brute force approach, first remove all headers and then re-add them until it compiles, if 'f1.h' is added first then the code will compile but the semantics of the program have been changed.
A similar rule applies when you have partial and specializations. It doesn't matter if the specialization is selected or not, you need to make sure that all specializations are visible:
// f1.h template <typename T> void foo (T); // f2.h template <> void foo (int); // bar.cc #include "f1.h" #include "f2.h" int main () { foo (0); // Calls specialization 'foo<int>(int)' }
As for the overload example, the brute force approach may result in a program which still compiles but has different behaviour.
Another related type of analysis that you can look out for is checking if types can be forward declared. Consider the following:
// A.h class A { }; // foo.h #include "A.h" void foo (A const &); // bar.cc #include "foo.h" void bar (A const & a) { foo (a); }
In the above example, the definition of 'A' is not required, and so the header file 'foo.h' can be changed so that it has a forward declaration only for 'A':
// foo.h class A; void foo (A const &);
This kind of check also reduces header dependencies.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With