Re: [PATCH] Re: 2.5.3-pre1 compile error

[dmeyer@dmeyer.net]

In article <20020116015513.L32088@suse.de> you write:
> On Tue, Jan 15, 2002 at 04:41:08PM -0800, Linus Torvalds wrote:
>  > > #ifndef _LINUX_POSIX_TYPES_H   /* __FD_CLR */
>  > > #include <linux/posix_types.h>
>  > > #endif
>  > If this actally makes any noticeable difference to compilation speed I
>  > could live with it. Does it?
> 
>  I'm sure I read somewhere that gcc is clever enough to know
>  when it hits a #include, it checks for a symbol equal to a
>  mangled version of the filename before including it.
>  (Ie, doing this transparently).
> 
>  Then again, I may have imagined it all.

I'm pretty sure you did, since it's perfectly legal (and occasionally
useful, if gruesome) to do

#define THE_STRUCT struct1
#include "struct_def.h"
#undef THE_STRUCT
#define THE_STRUCT struct2
#include "struct_def.h"

and have both #includes work.  You may be thinking of #import, which
is deprecated except for objective-c, IIRC.

In answer to Linus' question...yes, in a large system redundent
include guards can make a real difference, particularly for headers
which get included by other headers regularly.  OTOH, my last
experience using them was on an underpowered Solaris box, which (a)
didn't have enough memory for all the developers compiling on it and
(b) was running an old Solaris, so its read caching was pretty lame
anyway.  It makes rather a lot of difference if the preprocessor has
to read <linux/posix_types.h> from the disk 20 times or if it can get
it from the file cache 20 times.

-- 
Dave Meyer
dmeyer@dmeyer.net