Xref: utzoo comp.std.c:397 comp.lang.c:12777 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!voder!pyramid!prls!philabs!micomvax!ray From: ray@micomvax.UUCP (Ray Dunn) Newsgroups: comp.std.c,comp.lang.c Subject: Re: C function prototyping and large projects Message-ID: <1281@micomvax.UUCP> Date: 20 Sep 88 15:17:00 GMT References: <24@motto.UUCP> <3511@boulder.Colorado.EDU> Reply-To: ray@micomvax.UUCP (Ray Dunn) Organization: Philips Electronics Ltd. (TDS - Montreal) St. Laurent QC, Canada Lines: 44 In article <24@motto.UUCP> russ@motto.UUCP (Russell Crook) writes: >We are just starting to use function prototypes, and are looking for >suggestions on how to use them. >.... >Do you regenerate the prototypes automatically, every time you rebuild >or whenever the source file changes, or what? As others have said in various ways to the first part of the question - use function prototypes in the same way other global data is handled - include them in *appropriate* .h files - do *not* just use one big .h file for everything. Get into the habit of creating a prototype in an appropriate header file when you create a global function, in the same way you currently create any other extern statement. This .h file should be included in the "parent" source file, as well as in referencing files. If the procedure is static, put the prototype somewhere at the top of the source file. The answer to the automatic *generation* question is simple - do it once if your code has not used prototypes before (this is why MS provided the feature), disseminate the output into header files, then maintain the information manually as you would for any other global information. Continually re-generating prototypes can only lead to trouble, does not adequately separate "static" and "extern" declarations, and doesn't automatically get the information into the correct places. Define things as global only on a "Need to know" basis - i.e. put static in front of everything in sight! (:-)/2 Hopefully prototyping will increase the diligence of using that little word "static" when defining procedures which do not *need* to be global (desperately trying to avoid flaming the inappropriate overloading of the keyword "static" and the fact that the static/extern default is reversed from what it should be - something not worth arguing about because it is cast in 'C'oncrete)! -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090