Identifying unnecessary #includes

Aleix Pol aleixpol at
Wed Mar 31 20:38:12 UTC 2010

On Mon, Mar 29, 2010 at 10:52 PM, Bertjan Broeksema <b.broeksema at>wrote:

> On Saturday 27 March 2010 20:06:50 Casey Link wrote:
> > Hey KDev Devs,
> >
> > Amarok is working on re-organizing our code base, such that is is
> > compartmentalized into libraries with few inter library dependencies.
> > Over the years our source files have gathered many  #includes that are
> > cruft. Aside from manually going through hundreds of files and testing
> > via trial and error, we are looking for a way to identify and remove
> > unnecessary #includes.
> >
> > We figured KDev4 and its DU chains might be able to help us. Could
> > someone comment on this please?
> A lot of the information you need for such a task is available in the
> DUChain.
> However, the problem is tricky. I.e. define when an include is not needed!
> One problem you at least will have is the fact that the DUChain stores only
> information for one build configuration (i.e. the values of the defines).
> So
> what might look unneeded at a specific run on a specific machine on a
> specific
> OS etc. might be needed in another configuration.
> Another problem: often an include is not needed in the header when a
> forward
> declaration is added for the type specified in the included header.
> Additionally, it might be needed to add copy ctors and dtor (i.e. avoid the
> default implementations) to make a header really unneeded.
> Finally, a header might be needed for its preprocessor content and not its
> C++
> content.
> Well, lots of stuff to think about before declaring a header unneeded, hope
> this helps a bit. The DUChain offers you a lot of information, but you will
> still need to do quite some work imo to have a tool which takes in account
> the
> above described problems.
> I think the most important thing is to clearly describe when you consider a
> header as unneeded. Then, clearly describe for those cases what information
> you would need to determine if the header actually is unneeded. Then start
> with the easiest use cases, e.g. an included headers that have types and pp
> info defined that is not used at all. Then move on to the more trickier
> cases.
> Not an easy task, though it would be a very interesting addition to
> KDevelop
> =:).
> Cheers,
> Bertjan
> --
> KDevelop-devel mailing list
> KDevelop-devel at

Well, we can start having some tool that says which ones are definitely not
needed (which is what the plugin i added tries to).

I don't think it's about finding all the problems but about finding
problems, in the end it's still the developer who has to know what he's
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KDevelop-devel mailing list