This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: #import future (summary and proposed solutions)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: "Timothy J. Wood" <tjw at omnigroup dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 25 Jan 2003 22:08:50 -0800
- Subject: Re: #import future (summary and proposed solutions)
- References: <FECE609C-30F1-11D7-AF6F-0003933F3BC2@omnigroup.com>
"Timothy J. Wood" <tjw@omnigroup.com> writes:
> Consider the case that I'm using two packages from different vendors:
>
> <PackageA/header1.h> has:
>
> #include "header2.h"
>
> <PackageB/header1.h> also has:
>
> #include "header2.h"
>
> Both have the minimal '_FILENAME_H_' header guards w/o any sort of
> UUID (as is common practice), so the second header2.h will not get
> included. Yes, there are ways to avoid this problem, but it does
> happen.
I'm not sympathetic. The headers are buggy - they need to consider
their official short names to be packageX/headerY.h and their guard
macros should be chosen accordingly. Otherwise, there is a clash of
filenames, not just guard macros.
> You should always design for the common case (single inclusion).
> If K&R had seen far enough into the future, I'd hope they'd agree that
> a '#pragma allow_multiple_inclusion' would be a much better way to let
> the header declare that it wants to be included more than once.
If I were designing C from scratch I might agree with you.
zw