Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!mcnc!unc!steele
From: steele@unc.UUCP
Newsgroups: comp.lang.c
Subject: Re: Function prototypes (was: miscellaneous unrelated stuff)
Message-ID: <309@unc.cs.unc.edu>
Date: Tue, 5-May-87 12:29:09 EDT
Article-I.D.: unc.309
Posted: Tue May  5 12:29:09 1987
Date-Received: Thu, 7-May-87 02:32:53 EDT
References: <18346@ucbvax.BERKELEY.EDU> <7973@utzoo.UUCP> <796@rtech.UUCP> <1821@husc6.UUCP> <2023@bunker.UUCP> <731@sdchema.sdchem.UUCP>
Reply-To: steele@unc.UUCP (Oliver Steele)
Organization: University of North Carolina, Chapel Hill
Lines: 59

Eric Olson (olson@endor.UUCP) writes:
[about putting all the prototypes in a single header file]
}....  So I can prototype
}everything in a header file included in all my modules, but then adding a
}module forces a complete re-make.


Harry J. Gross (hjg@bunker.UUCP) writes:
)
)	It's kind of kludgey (sp?), but if you _know_ that the only change to
)the header was the addition of a prototype that is currently unused in any
)other module, you could *touch* each of the other modules (.c and .obj).
)Then make should leave them alone.
)	If there is a better way, I don't know what it is, BUT I SURE WOULD
)LIKE TO!!!


Tom Stockfisch tps@sdchemf.UUCP writes:
>
>The way I handle it is to have my declaration/prototype header file contain
>*only* declarations/prototypes, and then I DON'T MENTION IT IN THE MAKEFILE.
>I can't think of a single case when this has caused a typing problem.

The way I handle it, when I'm being modern and verbose, is to treat each
set of functions/globals that implements and abstract type or object Foo as
a module 'Foo' contained in two files, 'foo.c' and 'foo.h', which roughly
parallel the public and private parts of modules in Modula-2 and Ada (I
speak through my hat, not knowing either).  Any module that uses a foo then
#includes "foo.h".

Your price is more files, and more #included files, and maybe more compilation
time to #include them all (This overhead will probable be negligible on a
real UN*X machine.  On a Mac it's expensive to open files, but a 96-128K
cache speeds up recompilation enough that I don't worry about it under
Lightspeed).

Your payoffs are
1)  An automatic dependency diagram (either a short shellscript to collate
    #include-d files or option-click in the title bar to get a list of modules
    that a given file uses).
2)  You only force recompilation of a file iff the interface to a module it
    uses changes.  Their is no easy way to do this automatically if the
    granularity of header files is any larger than that of code files.

>The way you mess up in this case is to change a function's type in its
>module and forget to change it in the header file.  Mentioning the header file
>in the "Makefile" doesn't catch this error.

Including a module's header in its code file solves that.  The only problems
I've run into are in the management of modules large enough to be composes
of submodules.

------------------------------------------------------------------------------
Oliver Steele				  ...!{decfax,ihnp4}!mcnc!unc!steele
		      				steele%unc@csnet-relay.csnet

"Education and religion are two things not regulated by supply and demand.
The less of either the people have, the less they want."
						- Charlotte Observer, 1897