static in function definition

[Ravi]

What is the difference between following function definitions:

static int f1()
{
/* code here */
}

and

int f1()
{
/* code here */
}

 

[Malcolm McLean]

What is the difference between following function definitions:

static int f1()
{
/* code here */
}

and

int f1()
{
/* code here */
}

The function declared static can only be called from another function within
the same file. This is very useful in complex projects, because it
simplifies the connections between modules.

 

[Flash Gordon]

Malcolm McLean wrote, On 27/08/07 21:57:

The function declared static can only be called from another function
within the same file.

Incorrect. If can only be called *directly* from within the same
translation unit. Function pointers can and do get passed around
allowing functions declared static to be called from other translation
units.

This is very useful in complex projects, because
it simplifies the connections between modules.

True.

 

[Keith Thompson]

The function declared static can only be called from another function
within the same file. This is very useful in complex projects, because
it simplifies the connections between modules.

Actually, it means that the name is only visible within the same
translation unit (which, with #include directives, could consiste of
multiple files). If you take the address of f1, you can call it
indirectly from anywhere.

In most cases, you wouldn't want to do this; if you want to call it
from another translation unit, you don't make it static. But I can
think of cases where you'd want to be able to call a function
indirectly without making its name directly visible.

 

[Chris Thomasson]

[...]

In most cases, you wouldn't want to do this; if you want to call it
from another translation unit, you don't make it static. But I can
think of cases where you'd want to be able to call a function
indirectly without making its name directly visible.

[...]

Here is an example of using a table of pointers to "private" static
functions in a translation unit for use as a vtable in a minimalist
object-oriented C technique:

http://groups.google.com/group/comp.lang.c/browse_frm/thread/1b106926ba5db19f

So, IMHO, there are very legitimate reasons to pass function pointers to
static functions.

 

[CBFalconer]

What is the difference between following function definitions:

static int f1() {
/* code here */
}

and

int f1() {
/* code here */
}

The static function can only be called by code within the same
file, or code that has been passed a functional pointer to f1. The
name does not escape the particular source file involved. The
non-static name is visibile in all files at link time, and can
cause multi-defined errors, or peacefully link up as designed.

 

[cr88192]

The function declared static can only be called from another function
within the same file. This is very useful in complex projects, because it
simplifies the connections between modules.

yes, as others have noted, the name is hidden from other source files.

however:
int fl()
{
static int init=0;
...
}

is a little different, be careful not to confuse them...


in many tools, static toplevel declarations are handled at the assembler
level (non-exported symbols are not externally visible, or similar), wheras
in my comipler, this kind of thing is usually done by giving the values a
cryptic autogenerated name (my case, a 96-bit psuedorandom value encoded in
a base-48 scheme, partly because my assembler/linker internally assumes all
symbols are global).


as for the next point:
personally I dislike the use of using static declarations to hide functions
or variables in this way (primarily because the area in which I may need the
variable may infact be somewhat larger than a single source file, but not to
the level of whole-project, ...).


as a result, I tend to instead use special naming conventions.
as elsewhere:
<lib>_<part>_<name>

where for variables, it is usually an all lowercase scheme (as a result, for
global variables I may split name words with underscores as well).

for functions I typically use the FirstLettersAreCaps convention.
I rarely use camelCase, except sometimes in shared APIs (this is usually for
code where I separate the front-end api from the rest of the code in a
particular lib).

as an example (a part of my 3D-engine's entity system):
void LBXGL_Entity_GetPropertyFVector(LBXGL_Entity *ent, char *name, float
*fv, int n);

vs (an external API function for my physics lib):
void bsdeSet3FV(int obj, int val, float *fv);

where internally the lib uses a convention more like the above...

 

[karthikbalaguru]

It plays a great role in terms of scope of the function between
files .
It hides the name of this function from the other files so they cannot
use/call it.
But, there are ways to indirectly overcome that 'static' effect.
That is, Pointers to this function (Function pointers) can nullify the
static and make it accessible
across all the files.

Actually, it means that the name is only visible within the same
translation unit (which, with #include directives, could consiste of
multiple files). If you take the address of f1, you can call it
indirectly from anywhere.

Yeah, using the address, we can call it from anywhere.

Karthik Balaguru