Path: utzoo!attcan!uunet!mcvax!hp4nl!philmds!leo From: leo@philmds.UUCP (Leo de Wit) Newsgroups: comp.lang.c Subject: Re: C Style Message-ID: <918@philmds.UUCP> Date: 12 Jan 89 18:02:03 GMT References: <2688@ficc.uu.net> <9336@smoke.BRL.MIL> <2700@ficc.uu.net> <9345@smoke.BRL.MIL> Reply-To: leo@philmds.UUCP (Leo de Wit) Organization: Philips I&E DTS Eindhoven Lines: 29 In article <9345@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: |In article <2700@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: |-Depends on the number of open files the operating system and 'C' library |-allows, and on the cost of opening a file. If the files are large, this |-extra set of conditionals might significantly enhance compilation speed. | |Well, a good reason for nonetheless letting the compiler take care of it |for you is that otherwise the user of the header needs to also know the |special lock symbol for the header. General design principles argue that |the symbol should be the private property of the header. An argument against this is that if the user of the header does NOT need to know this, it could possibly #define the same symbol (for whatever reason). This would result in the header not being included properly. The strategy chosen should perhaps be such that one (or more ?) symbol(s) per file are being reserved for this purpose, so that each module or header file knows what symbols can / cannot be used. Peter's argument 'Depends on the number of open files' doesn't seem valid: if you don't use the lock symbol, you open the header file; since the whole header file is #ifdef'ed out, no other files will be included in the process. So the total number of files open at any time is at least one more than in the 'use the lock symbol' strategy. If your system can't handle that one extra open file, you probably had already too many open (read: abused the #include facility). Leo.