pjh@mccc.UUCP (Pete Holsberg) (01/27/89)
In K&R 2nd, they put function prototype declarations before main() in
programs on pages 24 and 119 (and probably others as well), but "in the
usual place" -- with the declarations of identifiers -- in the program
on page 72 (and probably others).
Does it make a significant difference? If so, what is it? Thanks.
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/28/89)
In article <584@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: >Does it make a significant difference? If so, what is it? Thanks. Not really; the external declarations remain in scope until the end of the translation unit and the internal ones go out of scope at the end of the block within which they're declared. For extern functions and data, there cannot be conflicting definitions anyway, so one might as well use file scope for their declarations. The only practical uses I can think of for hiding declarations of externs outside a block would generally be considered poor style. There are languages that require explicit "importing" of identifiers in order to use them in a block. Programmers who think along those lines may well prefer to write their C code like that. Personally, I prefer to finish the job of declaring externs just after the #includes that started the job near the start of the source file. It also usually saves on keystrokes (or mouse clicks, for "sam" users) since only one declaration is needed for each extern that way.
roetzhei@sdsu.UUCP (William Roetzheim) (02/01/89)
I may be the only one, but I like to put all of my function prototypes in one include file which contains only function prototypes. This simplifies separate compilation and testing and provides me with a ready index of the program's functions (and their parameters). Because my programs typically have many functions (hundreds), I keep the prototypes in alphabetical order within the file. WHR
rfarris@serene.UUCP (Rick Farris) (02/01/89)
In article <3449@sdsu.UUCP> roetzhei@sdsu.UCSD.EDU (William Roetzheim) writes: > I may be the only one, but I like to put all of my function > prototypes in one include file which contains only function > prototypes. This simplifies separate compilation and testing and > provides me with a ready index of the program's functions (and their > parameters). Because my programs typically have many functions > (hundreds), I keep the prototypes in alphabetical order within the > file. I used to do that, but on large projects, it's a royal pain to have to re-make the whole thing everytime you add another function to the prototype list. Now I create an include file for each source file, which includes the function prototypes for that source file. I call it filename.X, for external interfaces. Then I #include filename.X in each of the source files that use functions from filename.C. There's a rather good description of the whole process in "Portable C and Unix System Programming", by "J.E. Lapin" (actually the staff at Rabbit Software), published by Prentice Hall. Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@serene.cts.com ...!uunet!serene!rfarris serene.UUCP 259-7757
tjr@cbnewsc.ATT.COM (thomas.j.roberts) (02/04/89)
From article <372@serene.UUCP>, by rfarris@serene.UUCP (Rick Farris): > In article <3449@sdsu.UUCP> roetzhei@sdsu.UCSD.EDU (William Roetzheim) writes: > >> I may be the only one, but I like to put all of my function >> prototypes in one include file which contains only function >> prototypes. . . I do this, too, but use a tool to pull out all of the declarations from the files containing the definitions. This tool puts "/* foo.c */" ahead of the prototypes from file foo.c, so it serves as a (crude) index to functions. I do NOT make the object files depend upon this header file (called "proto.h"), nor do I automatically re-create proto.h whenever any .c files are modified; I need to explicitly re-create proto.h whenever I change the definition of, or add any functions. Tom Roberts AT&T Bell Laboratories att!ihnet!tjr