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