Subroutine layout in C
Matt Landau
mlandau at bbn.com
Sat Jan 7 04:56:58 AEST 1989
In comp.lang.c (<1987 at lznh.UUCP>), ariel at lznh.UUCP (<10000>Ariel Aloni) writes:
>>#define PRIVATE static
>>#define PUBLIC
>C is terse and accurate, if you want to invent new keywords for C
>please don't abuse CPP, design your own new language.
In general, this is good advice. If you're going to program in C, then
program in *C*; don't end up with something like the original /bin/sh
code, which no real C programmer ends up wanting to deal with. But . . .
>In your particular example the change of 'static' is very confusing
>since 'static' has a different meaning for functions and variables.
. . . on the other hand, this is precisely why an alias for "static"
may be a *good* idea.
One can argue that overloading static with two different meanings was
a flaw in the original language design -- there does not seem to me to
be all that much similarity between persistent variables in a function
and variables/functions that are hidden from other source files, so it's
not clear why you would want to use the same keyword to describe both.
Using something like PRIVATE for file-level static variables or functions,
and the traditional static for variables that persist across function
invocations, serves to make the distinction clear.
--
Matt Landau Waiting for a flash of enlightenment
mlandau at bbn.com in all this blood and thunder
More information about the Comp.lang.c
mailing list