Identifying unnecessary #includes

[Aleix Pol]

On Mon, Mar 29, 2010 at 10:52 PM, Bertjan Broeksema <b.broeksema at home.nl>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 kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>

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
doing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100331/df664537/attachment.html>