This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: #import future (summary and proposed solutions)
Peter Barada <peter@baradas.org> writes:
> What is the problem of #import anyway? If in a compilation unit an
> include file (after fully expanding its path) has been '#import'ed then
> another instance of '#import' on the samve file (that matches the
> fully expanded path) will skipp it since its definitons/declarations
> have already been seen in the token stream. I see this as a perfomance
> boon since the compier doesn't have to bother opening/reading the
> file.
Yes. However:
1) GCC will recognize a header file with an #ifndef wrapper around its
entire substantive content and skip re-reading it when it is
#include-d a second time, which provides all the performance
benefits of #import. It has done this since forever.
2) The implementation of #import will fail under certain circumstances
and cause a file to be read twice when it shouldn't have been.
This is also true of the #ifndef-wrapper optimization. However,
when the #ifndef-wrapper optimization fails the only effect is a
small amount of wasted time, because the #ifndef prevents the
content of the header from being seen twice. #import failing
causes the translation unit to be rejected spuriously.
3) #import is poor language design:
#import is not a well designed feature. It requires the users of
a header file to know that it should only be included once. It
is much better for the header file's implementor to write the
file so that users don't need to know this. Using a wrapper
#ifndef accomplishes this goal.
- quote from the CPP manual; this text has also been there since
forever.
zw