[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #import vs #include
From: |
Nicola Pero |
Subject: |
Re: #import vs #include |
Date: |
Sat, 3 Jan 2004 18:47:39 +0000 (GMT) |
> *SIGH*
> > Yep the G stands for GNU and the problem with #import is that it
> > is/was depricated (from gcc). But I don't know what the current/future
> > state of gcc will be. If the #import will be valid or that we still
> > need to use #include and ifdefs.
> In GCC 3.4 #import *IS UNDEPRECATED* We really need to pull together
> and clarify that in our documentation, IMO. Personally, I'd vouch for
> --enable-import being on in GNUstep-make by default in light of this
> FACT,
Pedantically speaking ;-), this is not very important: when #import is
undeprecated, using -Wimport or not using it on the compiler command line
does not make any difference. So, --enable-import or --disable-import
gives the same result: the compiler lets you use #import without
complaininig. :-)
Said that,
> and also that all documentation which contains this kind of FUD
> be changed to reflect this new reality.
I agree with you that we should remove/mitigate documentation against
#import.
As a last remark (out of the quarrel, just on practical terms), don't
forget that #include + include guards is expected to be compiled faster
than #import. How much faster, and/or whether that's relevant in
practice, is up to experimentation (and might depend a lot on the
filesystems you are using; I'd expect/hope that with all sources on a
normal linux filesystem you wouldn't almost see any difference in speed);
I've never seriously experimented with it.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: #import vs #include,
Nicola Pero <=