Headers including headers and precompilation

[Robert P. J. Day]

On Fri, 31 Mar 2006, 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, 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.

also, like i said before, this would cause all kinds of grief if that
single local "catch-all" header file were to change in an unexpected
way.  if every source file in your project never includes <stdarg.h>
because it knows it will get it from "myfoo.h" and "myfoo.h" ever has
to delete that include for some reason, you are *so* totally screwed.

also, it makes your source utterly non-portable.  you can't reuse that
source in another project unless you drag "myfoo.h" along with it.

i have no objection to "libbb.h" or "busybox.h" including system
header files.  clearly, that has to be done.  but for cleanliness, i
think all of the source files should *pretend* that they have to look
after their own header file inclusions.

rday

p.s.  if you think about it this way, the header file "libbb.h" should
naturally contain stuff related to the libbb stuff.  and as little
else as possible.