| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
The Gnu Compiler Collection, Version 3.4
The Gnu Compiler Collection, Version 3.4
Posted May 7, 2004 18:43 UTC (Fri) by nobrowser (guest, #21196)In reply to: The Gnu Compiler Collection, Version 3.4 by joib
Parent article: The Gnu Compiler Collection, Version 3.4
What are the good reasons?
In my own style, every header file is self-contained, #include-ing any other
headers that declare types and macros it mentions. This way people who edit
the top source file are free from worrying about the order of #include-s.
I dislike the idea of a single monolithic header file too, though, for a
different reason: it introduces unneeded dependencies. If you include the
monolithic header in all C files, and then modify _any_ header whatsoever,
everything will be recompiled.
Acutally, that's only true if you generate the dependencies automatically.
If you can keep the details of which source depends on which header and
maintain Makefiles manually you're fine. Still a headache, though.
(Log in to post comments)
The Gnu Compiler Collection, Version 3.4
Posted May 9, 2004 22:40 UTC (Sun) by alextingle (subscriber, #20593) [Link]
When lots of header files refer to one another, large project builds tend to become unmanagable. One change to a single header file can force the recompilation of hundreds of objects. This can slow development to a crawl.The preferred alternative is to use forward declarations where possible in the header file itself, and put the #include in the body file.