This is the mail archive of the
mailing list for the GCC project.
Re: tree.h vs include guard
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Stan Shebs <shebs at apple dot com>
- Cc: Devang Patel <dpatel at apple dot com>, gcc at gcc dot gnu dot org
- Date: 14 Aug 2002 05:27:58 +0200
- Subject: Re: tree.h vs include guard
- Organization: CodeSourcery, LLC
- References: <3D59C969.email@example.com>
Stan Shebs <firstname.lastname@example.org> writes:
| Devang Patel wrote:
| > We already have guard in our Darwin sources for tree.h
| We have it for a reason - tree.h is included (dubiously IMHO) in one of
| the PFE headers. I don't see a reason for the mainline to have it though.
Well, I was working on a pretty-printer for C and C++ when I noticed how
painful it was for not having tree.h protect against multiple inclusion.
| > I do not know, if there is particular reason for not providing guards
| > for headers.
| > At one time, I saw many headers without include protection guards.
| I thought the current policy was only to include guards if they were really
| necessary, and for most headers they aren't. In general GCC policy is to
| explicitly include every header needed by a source file.
That is what I did for c-pretty-print.[hc] which needed bits from
tree.h. and latter when I included c-pretty-print.h in cp/error.c I
got complaints from the compiler -- realizing minutes later that it
was because tree.h was being included multiple times. Not having
guard for tree.h means reorganization of the include each time a bits
is added somewhere. Not a scalable scheme, IMO.
Note that c-tree.h, c-common.h, cp-tree.h already have guards.