C function prototyping and large projects
will summers
will.summers at p6.f18.n114.z1.fidonet.org
Fri Sep 23 12:09:55 AEST 1988
In article <1281 at micomvax.UUCP> ray at micomvax.UUCP (Ray Dunn) writes:
RD> Continually re-generating prototypes can only lead to trouble, does not
RD> adequately separate "static" and "extern" declarations, and doesn't
RD> automatically get the information into the correct places.
Segrating statics is not a problem as long as the generator makes
a distinction between these (either has an option to only generate
for "extern"s or carries the distinction to the output). What other
"trouble" can it lead to?
RD> Define things as global only on a "Need to know" basis - i.e. put static
RD> in front of everything in sight! (:-)/2
Hear Hear!!
RD> Hopefully prototyping will increase the diligence of using that little
RD> word "static" when defining procedures which do not *need* to be global
Many will sneer, but my local "universal" include contains:
#define public /* nothing */
#define private static
'static' only gets used for storage duration, 'private' for linkage.
Consistently using 'public' serves 3 purposes:
1> It makes it easier for automatic header generators to find the publics.
2> It removes the temptation to take the shortcut of leaving the linkage
unspecified when the function really should be 'private'. In other
words it forces a decision to be made and puts the public and
private choice on even footing...
3> Closely related to <2>, it informs the reader that I -choose- to make
the function/variable public and it is in fact used in other files
(ie. check other files before mucking with it).
\/\/ill <tm>
--
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!18.6!will.summers
More information about the Comp.lang.c
mailing list