C function prototyping and large projects

[will summers]

 In article <24 at motto.UUCP> russ at motto.UUCP (Russell Crook) writes:
 > >Are there conventions about where prototypes are stored -
 > >do you put them in '.h' files, or right in the source file, or
 > >somewhere else?
 
Doug Gwyn writes:
 > Prototypes don't change the recommended C practice, namely use
 > header files to define/declare all interface information.  The
 > best approach is to use separate headers (and separate source
 > files) for each group of functionally related capabilities.
 > For example, "parse.h" would declare the parsing function(s)
 > that are of use to other parts of the application, and it would
 
Agreed.  In an environment that has an automatic prototype generator I find 
the following a convient way to implement that during development:
 
   parse.h  is the file included when using parsing functions.
      if the parseing functions are implemented in files parse1.c
      parse2.c and parse3.c, then parse.h contains
   #include "parse1.hp"
   #include "parse2.hp"
   #include "parse3.hp"
 
The compile script causes  foo.hp  to be automatically generated
whenever  foo.c  is compiled.  .hp generation *always* happens.  This slows
compiles but prevents "accidents" when .hp updating is left to an ageing
programmer's memory...
 
I guess it's possible to write a SED script to update the prototypes imbedded
in parse.h, but the script would need to "know" which .c files go with which 
.h and so be package dependant.
 
To keep the source conventional, .c files never #include .hp's directly. Only 
.h's #include .hp's. 
 
I find this more convienent than updating parse.h  whenever adding/changing
a function in parse?.c.
 
    \/\/ill <tm>
 


--  
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!18.6!will.summers