Headers including headers and precompilation

[Rich Felker]

On Fri, Mar 31, 2006 at 09:20:38AM -0800, Devin Bayer wrote:
> Robert P. J. Day wrote:
> >On Thu, 30 Mar 2006, Rob Landley wrote:
> >
> >>On Thursday 30 March 2006 10:33 am, Robert P. J. Day wrote:
> >
> >as it stands, a *lot* of the source files currently don't bother
> >including what would normally be required system header files just
> >because they count on getting those inclusions via "libbb.h".  so, one
> >day, "libbb.h" is restructured to not include that header file anymore
> >and, suddenly, lots of stuff breaks.
> >
> >for cleanliness, i don't think any source file should count on getting
> >its *system* header files via a *local* header file inclusion.  even
> >if it's redundant, i'd prefer to see all source files explicitly
> >include all of the system header files they would normally need.  if
> >you don't, you're just begging to have stuff break in surprising ways
> >down the road.
> 
> 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, but it also brings lots of unnecessary symbols and
definitions into the namespace of each file, increasing memory
requirements to compile, decreasing speed, and possibly causing
conflicts with names due to inclusion of unexpected headers.

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. If suddenly random headers were
including fcntl.h, this would obviously break. Maybe you think this is
bad/stupid (I might agree), but there are much more subtle cases of
the same thing. 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.

Rich