Path: utzoo!utgpu!water!watmath!clyde!ima!think!rlk From: rlk@think.COM (Robert Krawitz) Newsgroups: comp.lang.c Subject: Re: Making re-#includes harmless--a simple solution? Message-ID: <13395@think.UUCP> Date: 10 Dec 87 15:00:29 GMT Sender: usenet@think.UUCP Reply-To: rlk@THINK.COM Organization: Thinking Machines Corporation, Cambridge, MA Lines: 45 In article <2000@bloom-beacon.MIT.EDU> newman@athena.mit.edu (Ron Newman) writes: ]Many header files begin with something like ] ] #ifndef __SOME_UNUSUAL_NAME__ ] #define __SOME_UNUSUAL_NAME__ ] ]and end with ] ] #endif ] ]so that if you #include the file more than once, nothing bad happens. ] ]Why not change the semantics of "#include" to be: "if, while ]processing the current .c source file, I have already included this ]file once, then don't include it again"? 1) The same file may have multiple names (symlinks and/or hard links). How do you KNOW whether a file has been included? The only way is by defining an attribute that only that file will have. The easiest way to do this (aside from checking device/inumbers, which is not portable and may not work in some bizarre cases, or other system dependent hacks) is to #define a unique name. 2) There may be equivalent files (e. g. I may have my own version of something-unusual.h that I want instead of the system version) and I want to make sure the system version doesn't overload mine. 3) Sometimes it may be DESIRED to include the same file multiple times. ]That seems a lot cleaner than having to (remember to) put the #ifndef ]stuff into every header file. It would also eliminate problems with ]vendors who forget to do this to their standard header files. ]Is it too late to fix this for ANSI C?? Vendors who don't do this should fix their files, just like any other broken code. Users who don't remember to do this will get screwed, then they will learn, just like they remember not to dereference null pointers the first time they don't use a VAX. Artificial constraints like this to try to recover from simple programming errors just make compilers more complicated and bug-prone, and prevent the programmer from deliberately doing something which may be unobvious but useful. harvard >>>>>> | bloom-beacon > |think!rlk Robert Krawitzihnp4 >>>>>>>> .