Headers including headers and precompilation

[Devin Bayer]

Rich Felker wrote:
> On Fri, Mar 31, 2006 at 09:20:38AM -0800, Devin Bayer wrote:
> 
>>For what it's worth, I vote for the way I picked up and liked after 
>>programming
>>with Cocoa for a while.  Have a single local header that includes all system
>>includes used anywhere in the program, or at least in our case all SUSv3 and
>>linux ones.  The main advantage is less maintenance.  But it also avoids the
>>redundancy when local headers include a system header and so does the main.c
>>file.
> 
> IMO this is very bad practice. Not only does it hide what the real
> dependencies are,

The dependency is simple: SUSv3 and maybe Linux headers.

> but it also brings lots of unnecessary symbols and
> definitions into the namespace of each file, increasing memory
> requirements to compile, decreasing speed,

I assume you mean decreasing compile speed.  Wrong.  On a modern system
it's faster to use precompiled headers for the entire system then to use
even a single un-precompiled header.

> and possibly causing
> conflicts with names due to inclusion of unexpected headers.

Which is a good thing.  If you are using SUSv3 names in your program you
should change them.

> For example: in another project I work on, we use the name open() as a
> static, module-internal symbol for many modules, and export it via a
> struct full of function pointers.

Which is just going to confuse a new programmer using your code or make
it difficult to re-use that code in any project using open().

> It's not the responsibility of an author to make sure
> their static symbols do not conflict with unrelated system headers
> which they do not use.

It isn't hard, there are advantages, and nothing good comes from using standard
function names in other ways.  Including all the header files
makes it easier to find these conflicts, since the compiler will help you.

-- 
Devin Bayer