Headers including headers and precompilation

[Devin Bayer]

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.

The objection that used to be valid for this was it slows down compiles.  But
now we have precompiled headers.  Benchmarking my system, it's slightly faster
to load a precompiled header for all of SUSv3 then to parse a single system header.
The compile still works on older compilers but it's slower.  And dependency tracking
isn't an issue if the precompiled header only includes system headers which
should very rarely change.

-- 
Devin Bayer