static or non static

[Szabolcs Nagy]

this is probably only a stylistic question

what do you think to be better in a single .c file program, declaring
functions with static qualifier or without it?

eg:
#include <stdio.c>
static int add(int a, int b) {return a+b;}
int main() {
printf("1+2=%d\n", add(1, 2));
return 0;
}

is there any difference between the two?

static int add(..)
or
int add(..)

 

[jacob navia]

this is probably only a stylistic question

what do you think to be better in a single .c file program, declaring
functions with static qualifier or without it?

eg:
#include <stdio.c>
static int add(int a, int b) {return a+b;}
int main() {
printf("1+2=%d\n", add(1, 2));
return 0;
}

is there any difference between the two?

static int add(..)
or
int add(..)

Always use static for functions that are not referenced outside the
module in which they are defined. This helps to keep name conflicts low.

Note that function names are exported by default in C.

Besides,

If a function is not used and it is declared static, the compiler
will warn you. If it is not, the compiler can't know if it is used in
another module and you end up with many functions unused completely
taking place for nothing at all.

 

[Ben Pfaff]

what do you think to be better in a single .c file program, declaring
functions with static qualifier or without it?

I would generally use static. Single-file programs tend to grow,
and it's easier if they're done "properly" from the start.

 

[Richard]

this is probably only a stylistic question

what do you think to be better in a single .c file program, declaring
functions with static qualifier or without it?

eg:
#include <stdio.c>
static int add(int a, int b) {return a+b;}
int main() {
printf("1+2=%d\n", add(1, 2));
return 0;
}

is there any difference between the two?

static int add(..)
or
int add(..)

In theory I would recommend marking them all as static. In practice,
well, I tend to keep a specific "extern" header for others to include
since more functions than not are often used outside of the file they
are defined in.

 

[CBFalconer]

what do you think to be better in a single .c file program,
declaring functions with static qualifier or without it?

eg:
#include <stdio.c>
static int add(int a, int b) {return a+b;}
int main() {
printf("1+2=%d\n", add(1, 2));
return 0;
}

is there any difference between the two?

static int add(..)
or
int add(..)

The advantage of the 'static' is that you can later decide to
expand the system with a separate file, and not worry about the
fact that 'add' has already been defined. static makes it only
visible within the original file.

Using add() in an external C file requires all of 1. removal of the
static and 2. inclusion of a prototype in main.h, and 3. #include
"main.h" in the new file.

 

[Eric Sosman]

this is probably only a stylistic question

what do you think to be better in a single .c file program, declaring
functions with static qualifier or without it?

eg:
#include <stdio.c>

Unusual header name ...

static int add(int a, int b) {return a+b;}
int main() {
printf("1+2=%d\n", add(1, 2));
return 0;
}

is there any difference between the two?

static int add(..)
or
int add(..)

Use `static', even in single-module programs. Even if
the program never grows beyond a single file, the fact that
the compiler can "see" all the calls to add() may allow the
compiler to optimize it more aggressively, for example, by
compiling it in-line.

 

[Szabolcs Nagy]

Use `static', even in single-module programs. Even if
the program never grows beyond a single file, the fact that
the compiler can "see" all the calls to add() may allow the
compiler to optimize it more aggressively, for example, by
compiling it in-line.

thank you all the answers
i guess static is nicer solution then

but can it really matter with respect to the optimization?
may be the .o code contains the extern functions but what about the
executable?
i thought in situations like this (single-module program) the compiler
automatically handles every function as static in the final
executable.


as a final note:
i checked the src of traditional unix tools (which are mostly single-
modul programs) and found both conventions to be used (static and
extern functions)
also note that c-faq contains very little amount of information about
'static' (i'm not complaining i just expected more questions)

 

[Eric Sosman]

Szabolcs Nagy wrote On 09/18/07 14:09,:

thank you all the answers
i guess static is nicer solution then

but can it really matter with respect to the optimization?
may be the .o code contains the extern functions but what about the
executable?
i thought in situations like this (single-module program) the compiler
automatically handles every function as static in the final
executable.

Compilers (more generally, "implementations") differ in
the optimizations they employ. It is fairly common -- not
universal, but common -- to find that the compiler does most
of the optimizing, while a "linker" or "loader" does little
more than glue together precompiled modules. This division
of responsibility reduces the amount and complexity of data
the compiler must somehow encode for transmission to the
linker/loader, and also reduces the amount of work the L/L
needs to do; in some implementations this can also reduce the
program's startup time.

Now change the focus from the implementation to the
programmer who's dealing with it. You know something about
your program, like "The add() function is used only inside
its own module." Would you rather try to explain this to
the (relatively smart) compiler, using a mechanism built in
to the programming language, or would you prefer to hope that
the (relatively dumb) linker/loader will discover the fact for
itself, without even being given a hint?

General principle: The compiler is your friend, and you
shouldn't keep secrets from your friends. If you know an
identifier is needed only in one module, share your knowledge
with the compiler by writing `static'. If you know that an
integer cannot possibly be negative, let the compiler in on
the secret by using an `unsigned' type. If you know that a
function's pointer argument will not be used to modify what
it points to, write `const'. With C99 implementations, use
`inline' and `restrict' to help teach the compiler things you
know that it might not find out on its own. The compiler may
or may not make use of all you tell it, but at least it won't
make poor decisions out of ignorance.

One exception (for C) is the `register' keyword. It was
formerly used for just this kind of communication with the
compiler, but compilers have mostly outgrown the need to be
told. Indeed, the compiler likely has a better idea than
you do about just how many and what kinds of registers (or
whatever) are available, and how they can best be used, and
different compilers for different machines can adapt their
decisions more easily than you can rummage through your source
inserting and deleting `register' to suit each new platform.
It seems possible that `inline' may meet a similar fate as
compilers get smarter still.

as a final note:
i checked the src of traditional unix tools (which are mostly single-
modul programs) and found both conventions to be used (static and
extern functions)
also note that c-faq contains very little amount of information about
'static' (i'm not complaining i just expected more questions)

The fact that something now regarded as "best practice"
was not always seen as such should not be surprising. (The
idea that today's best practice may be tomorrow's deprecation
should also not be too alarming.) Unix tools did not spring
full-armed from the brow of Ken, but were written over a long
period at many places by many people. Uniformity of style is
not likely under such circumstances.

As for the FAQ, communicate with Steve Summit if you have
suggestions for improvement.

 

[Szabolcs Nagy]

[snip]

thanks your comment was very helpful