[comp.lang.c] External Functions

stan@Dixie.Com (Stan Brown) (03/15/91)

	I'v got a question.

	Given an externaly defined function (that is in a seperate source
	file)  used by two different functions in one source file.

	void foo();

	Which of the folowing would be better & why

	Choice 1
------------------------------------------------------------------

	extern void foo();

	void func1()
	{
	   .
	   foo();
	   .
	}


	void func2()
	{
	   .
	   foo();
	   .
	}
-------------------------------------------------------------------
or

	Choice 2
------------------------------------------------------------------

	void func1()
	{
	extern void foo();
	   .
	   .
	}


	void func2()
	{
	extern void foo();
	   .
	   .
	}
-------------------------------------------------------------------


-- 
Stan Brown	P. c. Design 	404-363-2303	Ataant Ga.
(emory|gatech|uunet) rsiatl!sdba!stan				"vi forever"

wirzenius@cc.helsinki.fi (Lars Wirzenius) (03/16/91)

In article <8146@rsiatl.Dixie.Com>, stan@Dixie.Com (Stan Brown) writes:
[Edited for brevity --Lars Wirzenius]
> 	Which of the folowing would be better & why
(1)
> 	extern void foo();
> 	void func1() { ... }
> 	void func2() { ... }
(2)
> 	void func1() { extern void foo(); ... }
> 	void func2() { extern void foo(); ... }

(1) is better, since the declaration needs to be written only once, so
there is less of a chance to introduce bugs when (not if) you change the
function declaration. You could improve on (1) by putting its
declaration (prototype if you have an ANSI compiler) into a header file,
and #including that into any source file that calls foo, and also into
the file that defines it (this is a handy way to ensure that
declarations and definitions stay in sync).
-- 
Lars Wirzenius    wirzenius@cc.helsinki.fi

stan@Dixie.Com (Stan Brown) (03/17/91)

wirzenius@cc.helsinki.fi (Lars Wirzenius) writes:

>(1) is better, since the declaration needs to be written only once, so
>there is less of a chance to introduce bugs when (not if) you change the
>function declaration. You could improve on (1) by putting its
>declaration (prototype if you have an ANSI compiler) into a header file,
>and #including that into any source file that calls foo, and also into
>the file that defines it (this is a handy way to ensure that
>declarations and definitions stay in sync).

	Makes sense to me.  But it raises the next logical question.  
	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
	make will want't to recompile some things that really don't
	need it every time we add a new function to extern.h

	This is undesriable on my system because of slow complie times.

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


-- 
Stan Brown	P. c. Design 	404-363-2303	Ataant Ga.
(emory|gatech|uunet) rsiatl!sdba!stan				"vi forever"

wirzenius@cc.helsinki.fi (Lars Wirzenius) (03/18/91)

In article <8298@rsiatl.Dixie.Com>, stan@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@cc.helsinki.fi