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: FSF GCC, #import and #pragma once


Geoffrey Keating wrote:-

> OK, then, I propose that:
> 
> 1. We undeprecate #import in GCC for objective-C.
> 2. The semantics of #import become that:
>    A. #import A followed by #import B will include B only if its content
>       differs from the content of A.
>    B. #import A followed by #include B will include B only if its 
> content
>       differs from the content of A.
>    C. #include A followed by #import B will include B only if its 
> content
>       differs from the content of A.
> 3. Users are warned that #import without multiple-include guards can
>    impose a compile-speed penalty.
> 4. #pragma once behaves as if the file was included with #import
> 
> The reason I propose this is that this is what I have to implement 
> anyway for Apple, and it'll save me work if I can just use the same 
> code in FSF cpplib.

All right.  However, the last paragraph is not in itself a good reason
for FSF GCC to implement something.

My proposal comes from a different perspective: #import is the only 
reason that we have a PITA in cppfiles.c w.r.t. multiple inclusion;
and that is before your patch.  I find it very attractive, from FSF
GCC's point of view, that we should be able to get rid of the current
issues (cpp_simplify_pathname and lstat etc.) completely with a scheme
along the lines I suggested, and just rely on the O/S to DTRT without
our trying to second-guess filesystem namespace issues.

I really don't want more baggage like checksumming etc. just for the
benefit of #import.  If the GNU Step and other non-Apple-front-end
Objective C users can get the benefit without the pain, then that's great.
Remember that it is Apple's stubbornness that is causing #import problems
w.r.t. compatibility anyway.  Apple is always free to do its own thing
in its front end.

Neil.


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