Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!apple!bloom-beacon!sloth.pika.mit.edu!scs From: scs@sloth.pika.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Re: declarations in include files: how do YOU feel? Keywords: declarations include Message-ID: <11318@bloom-beacon.MIT.EDU> Date: 11 May 89 02:07:01 GMT References: <179@larry.sal.wisc.edu> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: scs@athena.mit.edu (Steve Summit) Organization: Massachusetts Institute of Technology Lines: 37 In article <179@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes: >The situation is, suppose I have a bunch of routines that are packaged >into a lib.a, and there is an associated include file "lib.h" that >users need to include. Should the lib.h file contain extern declarations >for everything in lib.a? By all means. I'd say that this is the recommended standard practice. If you're using ANSI-style function prototypes, put the prototypes in too, of course. If you're not using prototypes, you may leave out extern declarations for those functions returning int. (You may also leave them in, for documentation purposes.) >disadvantage: "scope" is not micro-managed. labels are in scope >everywhere, even labels not used in actual references. I've never worried about micro-managing global scope. If it's extern, it's global, so any module may call it. Explicitly announcing their intention to call it (with their own extern declaration) doesn't provide much more information than does the actual call. (For the same reason, I think that extern declarations in local scopes are silly. I understand that many people like them, but I've never really understood why.) >case 2: "anal" approach. no declarations in lib.h. User needs >to type in the declarations in every function that makes a reference. >advantage (???): user sees declarations in same file as usage. >scope of labels is managed according to program design. The disadvantage here, which is that the declaration (and, worse, the prototype, if used) has to be replicated, with ripe possibility for error, especially if the declaration has to be changed. This disadvantage, I would think, far outweighs any loss of "micro scoping" caused by header file externs. Steve Summit scs@adam.pika.mit.edu