Displaying the #include hierarchy for a C++ file in Visual Studio

Viewed 78090

Problem: I have a large Visual C++ project that I'm trying to migrate to Visual Studio 2010. It's a huge mix of stuff from various sources and of various ages. I'm getting problems because something is including both winsock.h and winsock2.h.

Question: What tools and techniques are there for displaying the #include hierarchy for a Visual Studio C++ source file?

I know about cl /P for getting the preprocessor output, but that doesn't clearly show which file includes which other files (and in this case the /P output is 376,932 lines long 8-)

In a perfect world I'd like a hierarchical display of which files include which other files, along with line numbers so I can jump into the sources:

source.cpp(1)
  windows.h(100)
    winsock.h
  some_other_thing.h(1234)
    winsock2.h
9 Answers

There is a setting:

Project Settings -> Configuration Properties -> C/C++ -> Advanced -> Show Includes

that will generate the tree. It maps to the compiler switch /showIncludes

The compiler also supports a /showIncludes switch -- it doesn't give you line numbers, but can give a pretty comprehensive view of which includes come from where.

It's under Project Settings -> Configuration Properties -> C/C++ -> Advanced -> Show Includes.

We have found IncludeManager to be a very powerful tool. It is not free (but not expensive) and it allowed us to get a grip of our Include issues and drop our compile time from 50 minutes to 8 minutes by pruning out large chunks of includes we weren't using.

There is now a plugin for Visual Studio called IncludeToolbox. It can list your dependent includes and do more things like a random remove and compile to see if that include was required.

Here is a good 3rd-party, FOSS tool. You can export results to XML, which will include data on number of occurrences and line numbers.

cl /P should show you the line numbers, such that you can tell the context of where a header file is being included from.

If you grep out the lines with ...

grep "^#line" file.i

... then you should have a pretty clean indication of what files were encountered in order by the preprocessor.

If it's a one off incident this should be a pretty quick diagnostic.

Related