[OT] Re: import

[Pascal Bourguignon]

Nicola Pero <n.pero@mi.flashnet.it> wrote:
> 
> > > #import is deprecated - on technical grounds - by any gcc compiler hacker
> > > we had the chance of talking to, both GNU and Apple folks - they have
> > > strong views on that point and they keep the warning turned on in the
> > > compiler by default.
> > 
> > As a complete ObjC newbie -
> > *why* is it deprecated?   Does #import  work anything like the Java import, 
> 
> I'm not much inside this, but I think it's because the languages are very
> different - 
> 
> in Java it's very easy to implement import.  import imports a *class*.
> when the compiler reaches an import, it checks if it has already imported
> that class or not.  That's it.
> 
> in C/ObjC, #import instead imports a file - which makes it not really
> clearly defined because different physical files on disk might contain the
> same code - but you don't want the same code to be loaded more than once
> (that's the whole purpose of #import) so the compiler has to guess ... it
> could check that the files are the same ?  but what if they are different
> versions of the same header ... they are different physically on the disk,
> but should never be included twice ... all this which looks silly but then
> might turn into very complex stuff for the compiler writer and might
> actually cause some real mess with complicated system libraries when you
> have multiple versions installed and a serious risk on including different
> versions twice.  I'm sure I read somewhere on the net a very definite
> tricky example of a real-world case which was fooling gcc's #import into
> loading the same file (with different versions perhaps) twice and crashing
> compilation.  Unfortunately I can't seem to find it any longer.
> 
> Anyway my explanation is probably incomplete and confused, but should give
> you an idea of why the problem arises.

It  does not  matter.  This  kind  of problem  is not  handled by  any
compiler/language. What if you defined  two classes with the same name
in different files with different path? Whatever the language, you can
confuse  the  compiler  with  links  to the  same  file.   Programming
languages/compilers don't impose any mapping between objects described
in the  language and files  (that would link  the language to  a given
file  system!).   That's  why   it's  usefull  to  have  higher  level
constructs  in  the  language  such  as  packages,  modules,  classes,
whatever.

The #import  CPP directive is defined  as including a  given file once
ever in a  compilation run, and that's enough to  be an improvement to
#include.   It's a  higher level  construct than  #include  because it
imposes a  more structured  handling of the  files than  #include, one
that is  more usefull  in big  project than the  ability to  include a
given "header" several times, be it with the same macro environment or
not, because  it help programmers  avoid small errors in  writting the
pattern  #include+#ifndef+#define, and  because it's  more meaningfull
when  we program  objects with  one class  per couple  of  interface /
implementation files.

 
> Defining a preprocessor tag inside the header file itself seems to be the
> only real way of fixing this problem in C.  The only thing I can think of
> to make this prettier but still reliable would be to extend C (or ObjC)
> adding a
> 
> #declare GNUSTEP_H_APPKIT
> 
> directive (or whatever the name), which would only be allowed as the first
> command in a file, and would cause the compiler to behave as if 
> 
> #ifndef GNUSTEP_H_APPKIT
> #define GNUSTEP_H_APPKIT
> 
> where at the beginning and #endif at the end of file.  The #declare would
> declare a programmer-level tag marking the file, with the convention that
> no two files with the same tag should be loaded ever.
> 
> Then, you could use #include in the same way as you use #import.  You
> would only have to add #declare GNUSTEP_H_APPKIT at the beginning of each
> header file. This might make pascal happy I suppose :-) as a single
> #declare per file is pretty high-levelish IMO and the compiler people as
> well, because it would be well defined, reliable and efficient.
> 
> Anyway, in general #ifdef/#define looks like a minor annoyance after all.  
> It's a C thing, difficult to loose.


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------