67 lines
2.3 KiB
Plaintext
67 lines
2.3 KiB
Plaintext
At one time, I was of the opinion that an external should
|
|
be declared each time it was used. For example:
|
|
|
|
foo ()
|
|
{
|
|
extern long foobar ();
|
|
auto long fooval;
|
|
|
|
fooval = foobar ();
|
|
}
|
|
|
|
This way, complete functions can be lifted intact from
|
|
one file, and transported somewhere else without tracking
|
|
down all the appropriate extern declarations.
|
|
|
|
There are at least two problems with this:
|
|
|
|
1. There may be several dozen such declarations
|
|
inside each function. This is a pain to
|
|
type in and maintain consistent with all
|
|
other such declarations. (Not to mention
|
|
the visual clutter they cause.)
|
|
|
|
2. Typically functions also use preprocessor
|
|
facilities such as manifest constants
|
|
or macros, which are defined somewhere
|
|
else anyway, thus negating the positive
|
|
tranportation effect of declarations
|
|
internal to each function.
|
|
|
|
Because of these, and some other more subtle interactions,
|
|
I was converted to the school of placing all external
|
|
declarations in a single header file that every module
|
|
uses.
|
|
|
|
This presented problems of it's own:
|
|
|
|
1. Everytime a new declaration is added to the
|
|
header file, every single module will be
|
|
recompiled when using make. You start
|
|
recompiling things by hand or else defeating
|
|
make by "touching" things in appropriate
|
|
sequence to get only the recompilations that
|
|
you think are necessary. Sometimes you think
|
|
wrong, which was the problem make was invented
|
|
to solve in the first place. This is a very
|
|
non-trivial problem with big programs that
|
|
may take significant fractions of an hour
|
|
to recompile everything.
|
|
|
|
2. When the "externs.h" file gets quite large,
|
|
the overhead of processing it becomes noticable
|
|
with small code modules.
|
|
|
|
3. When code is reused somewhere else, you must
|
|
track down and extract all appropriate declarations
|
|
from the header file.
|
|
|
|
|
|
I have now settled on a compromise. All externals requiring explicit
|
|
declaration are grouped in one place at the start of each code
|
|
module. This is slightly harder to maintain when changing the type
|
|
of an extern, since they must be tracked down and changed in each
|
|
module that references them, but at least they are all in one
|
|
place in a given module. There are also other small problems but
|
|
all in all, this seems to be the most reasonable procedure.
|