Re: [OT] Identifying unused include directives?

[Devang Patel <dpatel at apple dot com>]

On Saturday, August 30, 2003, at 8:35 AM, Robert Dewar wrote:

> > What is "unneeded"?  On some systems, some header files pull in
> > others, and are therefore unnecessary from a GCC perspective, but they
> > are actually required to make the program portable.
>
> I think the definition of unneeded is pretty clear. A reasonable 
> definition
> would be that the removal of the #include would not affect the 
> semantics
> of the resulting program. As I pointed out before, this is recursively
> undecidable in the general case.

Darwin GCC 3.1 and earlier Darwin GCC compilers support preprocessor
known as cpp-precomp (develoepd by Apple/NeXT). It supports pre-compiled
headers at preprocessor level and it is used as default preprocessor for
C and Objective-C.

When, valid pre-compiled header is found, cpp-precomp only supplies
required (or needed) declarations to compiler. Which means, it is smart
enough to know what is needed and what is not required. If it can decide
it declaration level, it'd be possible to decide if header is required
or not.

Example:

	$ cat a.h
	#include <stdio.h>
	#include <stdlib.h>

	$ cat a.c
	#include "a.h"
	int main()
	{
        printf ("Hello World\n");
        return 0;
	}

Now if, a.h is a pre-compiled header then preprocessor supplies only 
following
stuff to compiler

	$ gcc3 -E a.c
	# 1 "a.c"

	# 1 "a.h" 1


	# 261 "/usr/include/stdio.h" 1
	int printf ( const char * , ... ) ;
	# 1 "a.h" 2


	# 1 "a.c" 2

	int main ( )
	{
	printf ( "Hello World\n" ) ;
	return 0 ;
	}

So here, it is possible for cpp-precomp to detect that stdlib.h and
other headers included by  stdio.h are not needed.

And because of this cpp-precomp feature, PCH is not able to achieve
same speed up as cpp-precomp, in some examples.

Its different story for C++.

--
Devang


> Yes, as you point out, in some cases, you want the #include present 
> even
> if this criterion of no semantic effect is met, but that's why this is 
> a
> warning, warnings always carry the danger of some false positives (or 
> they
> would not be warnings :-)