This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tree.h vs include guard


Stan Shebs <shebs@apple.com> 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.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]