This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Projects for beginners
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: Projects for beginners
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Fri, 02 Feb 2001 10:37:20 +0000
- cc: brane at xbc dot nu, gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Organization: ARM Ltd.
- Reply-To: Richard dot Earnshaw at arm dot com
> It also effectively sets those dependencies in concrete. If, for any
> reason, the dependencies change for a particular header, you have to
> change all sources that include it.
>
> From a conceptual point of view, you do anyway. A header is a specification
> of something which is implemented in a .c file. If the specification
> of something changes, you have to look at all callers to make sure they
> reflect the change of specification.
Not necessarily. Header files describe a set of interfaces. If I add a
new interface to a particular module it may require that a new header be
included first (as a hypothetical example rtl.h might change from not
requiring bitmap.h to requiring it). However, unless I make use of that
new interface in a particular C file, say wibble.c, nothing there has
changed. With the nested includes model I don't have to change wibble.c
at all. With your flat includes model I have to add the new #include to
wibble.c.
IMO each C file should directly include just those header files whose
interfaces it directly uses. It shouldn't have to directly include a
different set just to make the header file valid. In this way, the list
of header files at the top of a file is the list of interfaces used by
that file.
R.