External Functions

[Lars Wirzenius]

In article <8298 at rsiatl.Dixie.Com>, stan at Dixie.Com (Stan Brown) writes:
> 	If We put it in a .h file should we have one of these for eache
> 	source file that contains calls to externaly defined functions?
> 	Or should we put all the external functions into say exter,h
> 	and imclude this everywhere.  Obviously if we do this

Personally I would split the project into modules, such that each module
contains functions that 'belong together', e.g. one module contains only
functions that do keyboard related stuff, another defines a (major) type
and functions to manipulate that type. Each module has exactly one
header file, which contains everything that the module 'exports', i.e.
data types, function prototypes, #defines etc. Each module also has any
suitable number of .c files that contain definitions of functions and
other things don't belong to the header. If necessary, a module may
contain 'private' headers, not to be included in other source files.

> 	On the other hand if we have lots of include files we are back
> 	to a maintenece headeache again.

I think "my" method should be fairly good also from a maintenance point
of view, since logically separated things are also separated in
different source files, which makes it easy to change e.g. the
implementation of a module, as long as the interface stays identical. It
should also be easier to distribute the work if the modules stay
separate, not to mention testing each module separately.

However, I am by no means an expert on large projects (probably on
nothing :-), so comments from more experienced people would probably be
in order.

-- 
Lars Wirzenius    wirzenius at cc.helsinki.fi