I'm experimenting with static globals in C. I tried this code and ran nm on it:
#include <stdio.h>
static int global_static = 12345;
int main(void)
{
static int local_static = 12345;
printf("%d\n", global_static);
printf("%d\n", local_static);
return 0;
}
Here's a snippet of the nm output:
00004020 d global_static
00004024 d local_static.1905
000011a9 T main
I have two questions about this:
Where does the name for the local static variable come from? Is it a process ID or a random number?
Does the fact that global_static has no invalid characters in it imply that I could do extern static int global_static; in another file and read global_static?
When I say invalid characters, I mean characters that can't be part of variable names in C, i.e. ., $, %, #, etc.
Where does the name for the local static variable come from? Is it a process ID or a random number?
In gcc's langhooks.c, the default set_decl_assembler_name hook implementation (which is used directly for the C language) contains:
/* By default, assume the name to use in assembly code is the same
as that used in the source language. (That's correct for C, and
GCC used to set DECL_ASSEMBLER_NAME to the same value as
DECL_NAME in build_decl, so this choice provides backwards
compatibility with existing front-ends. This assumption is wrapped
in a target hook, to allow for target-specific modification of the
identifier.
Can't use just the variable's own name for a variable whose scope
is less than the whole compilation. Concatenate a distinguishing
number - we use the DECL_UID. */
if (TREE_PUBLIC (decl) || DECL_FILE_SCOPE_P (decl))
id = targetm.mangle_decl_assembler_name (decl, DECL_NAME (decl));
else
{
const char *name = IDENTIFIER_POINTER (DECL_NAME (decl));
char *label;
ASM_FORMAT_PRIVATE_NAME (label, name, DECL_UID (decl));
id = get_identifier (label);
}
And the comment on the macro DECL_UID says:
/* Every ..._DECL node gets a unique number. */
So the number is some identifier invented by gcc which is guaranteed to be different for every declaration seen in the translation unit (including declarations in #include-d files). This is enough to make sure if different scopes use local static variables with the same name, they will have different mangled symbol names in the assembly and object code.
Does the fact that global_static has no invalid characters in it imply that I could do extern static int global_static; in another file and read global_static?
No. For one thing, it's illegal to combine extern and static, since these give conflicting linkages to the variable. Note that static has two entirely different meanings in C: Inside a function, it means the variable has static storage duration. Outside a function, it means the variable or function has internal linkage. (A variable which is not local to a function always has static storage duration.)
So from the C language point of view, the static on global_static means that the variable has internal linkage, which means it is never to be considered the same variable as anything in any other translation unit, so there is no way to directly access it from another *.c file. When translating to ELF objects or other common object formats, this is done by making the symbol for the variable a "local" symbol instead of a "global" symbol. When linking executables or loading dynamic libraries, a global symbol can satisfy an undefined symbol from another object, but a local symbol never does.
Note the nm tool prints uppercase symbol type letters for global symbols and lowercase symbol type letters for local symbols, so the d next to the variables in your output means that both are local symbols and cannot possibly be directly used by other objects.
It's a unique identifier within the translation unit (source/object file), so that same-named static with different local scopes would not refer to the same object.
No. Symbols not tagged as global in an assembly/object file cannot be used to resolve references from other files at link time; they're ignored. (The lowercase d from nm indicates that it's a local symbol not a global one.) Within the same assembly/object file, the C source level rule that you can't have both external and static objects with same identifier at file scope rules it out.
Related
my first question here.
can anyone explain to me the differnce between a global static variable (that is, defined above the functions and the "main" combined with "static") and a static variable that is defined inside a function?
as i understand it, they do the same - both enlarge the variable scope to the whole file, and both restrict it to the specific file. so... what am i missing?
plus another question (that came up when looking for a solution) - what is extern? i thought that defining a variable above the main would make it global (as in to other files too), but then i read someone explaining that in order to do so, i must add "extern" before the varible defining.
For variables defined outside of a function, the static keyword limits the variable to being referenced using its identifier from the file in which it is defined. Variables of this type will be assigned a fixed address by the linker (outside of the heap and stack), but will not be assigned a global symbol. If variables of this type are defined in multiple files with the same identifier, the linker should allocate separate memory in each case and should compile without warnings.
Variables defined with the static keyword inside of a function have similar memory allocation, but references to the variable using its identifier are limited to within that function. You could have multiple functions defining static variables with the same identifier and each will be allocated separately.
If an initializer is used for static variables, the variable is initialized once before the program begins executed and the initializer is evaluated at compile time. The initializer must evaluate to a constant expression in this case (no function calls or parameter or variable references).
The compiler will typically build each C file independent of all of the others in a program using symbols to define external dependencies, such as variables and functions located in other files. After each source file is compiled, the linker processes the compiler output to replace symbols with fixed addresses and build the entire program. In order to properly execute the build, the compiler must know the types and sizes of all external functions and variables. The type and number of parameters and return type of functions are typically shared in a header file using function prototype declarations. Function prototype declarations are implicitly identified as external by the compiler. The extern keyword is used to specify the type and size of variables declared in files outside of the file referencing the variable. Declaring a variable without the external keyword would cause it to be defined within the module where it is declared. If two variables with the same identifier are declared in multiple files without the static keyword, then the compiler will typically generate an error since the same global symbol is used multiple times in the program.
#include<stdio.h>
static int a=5;
main()
{
static int a=15;
printf("%d\n",a);
}
So, how are both variables a stored in internal memory?
How are global and local variables with the same variable names stored internally in memory?
#include<stdio.h>
static int a=5;
int main()
{
printf("%p\n",(void *)&a);
static int a=15;
printf("%p\n",(void *)&a);
return 0;
}
Output for the upper program is
0x564e6b67a030
0x564e6b67a034
So you can see that both are stored in different addresses. As one is a global variable and other is local.
The names are only of interest to the human reader and the compiler/linker translating that code to machine executable code. The final object code resolves these to addresses and the names no longer exist.
The compiler distinguishes these the same way you do - by scope; when two identical symbols in the same namespace are in scope simultaneously, the symbol with the most restrictive scope is visible (i.e. may be accessed via the name).
For symbols with external linkage (in your example there are none other then main), the compiler retains the symbol name in order to resolve links between separately compiled modules. In the fully linked executable the symbol names cease to exist (except in debug build symbol meta-data).
The thing is the scope don't let them mess up. The first one has file scope and the other has block scope. (They are different variables - they are stored in separate memories.)
When you use it in the block - compiler checks whether this reference is resolved by anything in the same block. It gets one. And done.
And in case it is in some other function - if it doesn't find anything named a - the search ends in file scope where it finds the name a. That is where the story ends.
Both being static their storage duration is same. They live till the program exists. But their scope is different. If the scope was same too - compiler would have shown you error message.
Here if you compile with -Wshadow option - it will warn you about shadowing a variable. You shadowed the outer a with the inner on that block. That's it.
The facetious answer is that they are stored in different places.
Remember that the names of variables do not (normally) form part of the compiled program, so the compiler just follows the normal rules of variable shadowing. So in your case your print function (that's not a standard C function by the way - did you mean printf?) outputs the a declared in main. The fact that you've used the same name will not bother the compiler at all.
Finally C provides no way of accessing the global scoped a once the other declaration is encountered in main as it's static. (It is wasn't static you could use extern.) See How can I access a shadowed global variable in C?
I have the following files:
main.c:
#include "ext.h"
#include "main2.h"
#include <stdio.h>
int main () {
// printf("main - internal_static_variable: %d\n", internal_static_variable);
// printf("main - internal_static_variable: %d\n", internal_static_variable);
printf("main - external_variable: %d\n", external_variable);
put_static_val(24);
put_val(42);
printf("main - internal_static_variable: %d\n", get_static_val());
printf("main - internal_variable: %d\n", get_val());
++external_variable;
print();
}
main2.h:
// main 2.h
#pragma once
void print();
main2.c:
// main2.c
#include "ext.h"
#include "main2.h"
#include <stdio.h>
void print() {
printf("main2 - external_variable: %d\n", external_variable);
printf("main2 - internal_static_variable: %d\n", get_static_val());
printf("main2 - internal_variable: %d\n", get_val());
}
ext.h:
// ext.h
#pragma once
extern int external_variable;
void put_static_val(int v);
int get_static_val();
void put_val(int v);
int get_val();
ext.c:
// ext.c
#include "ext.h"
static int internal_static_variable = 0;
int internal_variable = 1;
int external_variable = 2;
void put_static_val(int v) {
internal_static_variable = v;
}
int get_static_val() {
return internal_static_variable;
}
void put_val(int v) {
internal_variable = v;
}
int get_val() {
return internal_variable;
}
When compiled and executed, the result is the following:
main - external_variable: 2
main - internal_static_variable: 24
main - internal_variable: 42
main2 - external_variable: 3
main2 - internal_static_variable: 24
main2 - internal_variable: 42
As expected, the variables not exposed in the header file (internal_static_variable and internal_variable) are not directly accessible.
What I don't get is the meaning of static. I know it limits the scope of a variable to the compilation unit, but isn't it enough not to declare a variable in the header file to hide it?
Also, I assumed that the static variable and the not-static variable would behave differently. Specifically, internal_static_variable would not be shared by the files including it (one instance for main.c and one for main2.c), but since I change its value from main.c and I get the changed valued in main2.c, there seems not to be any difference between the two.
Could you explain it, please? Thanks
Scope and Linkage
Identifiers have two properties that are relevant here: scope and linkage.
Scope is where an identifier is visible. You apparently already know that scope is limited to the file an identifier is declared in, and it may be further limited to a block or a function (or a function prototype) depending on where the identifier is declared and the keywords (such as static or extern) used when declaring it.
Linkage is a way of making different declarations of an identifier refer to the same object. There are three types of linkage: external, internal, and none.
If an identifier has internal linkage, it is not linked with identifiers in other translation units. An object called foo in one translation unit1 cannot be accessed by name in another translation unit.2
If an identifier has external linkage, it can be accessed in another translation unit by declaring an identifier with the same name and also with external linkage. When the program is linked together, identifiers with external linkage are resolved by the linker so that they refer to the same storage.
Problems With External Linkage
You can omit static and leave your identifiers with external linkage. As long as you are the only person writing your program, you can avoid problems. But this is not tidy; it leaves some things dangling, which can cause problems.
If you are writing routines to be used in other programs, leaving private identifiers with external linkage can be a problem, especially if they have simple, common names. A person who is using your routines in their own code might use the same name coincidentally, and then your two identifiers would be linked to the same object even though you need them to be different.
This can also occur intentionally. If you write a popular software package and leave private names with external linkage, some users of the package may explore what names are present and try to use them. This can result in people creating software which makes use of things in your software that were supposed to be private. Then you cannot develop new versions of the software that change the private parts without breaking existing software. That becomes a business problem. You may need to implement new algorithms inside the software package, but you do not want to break the existing source code of your customers. Declaring the names with static originally could avoid that.
How Declarations Affect Linkage
When an identifier is declared with static at file scope, it has internal linkage. Beyond that, the rules for which linkage an identifier has are a bit complicated, due in part to history of how the C language developed:
Declaring an identifier with extern gives it external linkage if no prior declaration is visible.
If there is a visible prior declaration, extern leaves the identifier with the same linkage as in the previous declaration.
A declaration of a function or an object at file scope without extern or static gives the identifier external linkage.
A declaration of an object at block scope without extern has no linkage, even if static is used.
Function parameters have no linkage.
Identifiers of things that are not objects or functions (such as type definitions) have no linkage.
Within one translation unit, each declaration of an identifier with internal linkage denotes the same object or function. Each declaration of an identifier with no linkage denotes a unique entity. (This paragraph is a direct quote from C 2011 [N1570] 6.2.2, and the other information in this answer comes from there too.)
Footnotes
1 A translation unit is the combined source code resulting from all #include directives. I use the technical term “translation unit” rather than “source file” because an object called foo in one source file could be accessed in another source file by using the #include directive.
2 An object with internal linkage can still be accessed in another translation unit by using a pointer, if you pass its address from one function to another.
If you define a non-static global variable, it's still global. Even if it's not declared in a header file, it can still be declared in another translation unit.
When a variable is extern (the default), the object file generated by this compilation unit will carry a named reference to its location. Whenever another object file is linked with the first and refers to the same named variable but does not provide its own definition, the linker will replace all instances of its use of that variable with its location. The CPU deals with memory locations during execution not variable names. This is why it being omitted in the header does not matter; later when you link the object files created from your .c source files, only then are global references resolved.
Static (outside of functions) is useful in that a single library/program can have multiple globally accessible variables under the same name. This prevents name collisions between modules which may both use a variable name for different purposes but make sense in their own contexts to use a variable name which just happens to be the same. As long as the variable is only needed in the current compilation unit, then you should make it static.
What I don't get is the meaning of static. I know it limits the scope
of a variable to the compilation unit, but isn't it enough not to
declare a variable in the header file to hide it?
That would not prevent the variable being declared and therefore becoming accessible. It is the difference between security and obscurity. By declaring it static it cannot be accessed externally by name, by simply not declaring it in a header you are only preventing access to those who do not know its name and data type. A more likely scenario is that your object code or library is used elsewhere and you get an accidental name clash - such bugs are often difficult to fathom.
I assumed that the static variable and the not-static variable would
behave differently. Specifically, internal_static_variable would
not be shared by the files including it (one instance for main.c and one for main2.c), but since I change its value from main.c and
I get the changed valued in main2.c, there seems not to be any
difference between the two.
Your code does not modify internal_static_variable in main.c; it modifies it only in ext.c. ext.c happens to expose internal_static_variable through an accessor function, which in your example provides minimal protection, but as a single point of write access, provides a number of advantages over direct access to the variable, such as:
It is possible to include code in the accessory to handle invalid input, by asserting, returning an error value, aborting, ignoring the value and not modifying the variable, or coercing to a valid value for example. Such code might also be conditionally compiled so that it only performs checking in a debug build.
The accessor function provides a single point in the code to place a debugger breakpoint to trap all write accesses.
For our assignment we have to code a program in C, but it says not to use external variables in the program. Does this mean variables in other files brought into the main code, or am I unable to use variables in the same file if they're not in the same function? (ie: could I pass a value into a function as an argument and have it return a value that may have to do with a variable in that function and set the return value equal to something, or is that using external variables?)
I've Googled around but it's not exactly clear, and I want to make sure, as this is rather important.
Just to be sure, I'd make all my variables part of a function, and either pass them as parameters or return them from the functions.
There are at least two interpretations of external variables.
First off, we have the extern keyword, which basically symbolizes what you would call a global variable. It's a variable declared in multiple translation unit, but it only exists in one place in memory. It is initialized in a single file and all subsequent changes affect every scope the variable is used in:
//globals.cpp
int x = 1337;
//main.cpp
extern int x;
int main()
{
//x is 1337 here
return 0;
}
The second meaning could be a variable that is declared and defined in class scope, but not used as extern. However, you could consider it external to the methods.
//main.cpp
int x = 1337; //is this external?
//could be, remove it just to be safe
int main()
{
return 0;
}
Let's go with all the possible cases, because from your question I'm not too sure either:
There is extern as a keyword. In order to understand this, you need to understand compilation units. Basically, each file is a compilation unit - so each .c is compiled to a .o with the headers substituted in place. In each compilation unit, you forward declare symbols you expect to use - functions belonging to other compilation units, for example.
Now, if you declare a global variable in one .c file, it is global wrt that file, but does not exist as a symbol in any other file at all - the compiler will error because it doesn't know where that variable was declared.
(Of course, if you declare the variable in a header - it will exist in all of the objects the header is included in, and then the linker will sulk, because when it links all the objects up some of the symbols will have the same name).
To get around this, it is possible to define a variable with extern int x;, for example. This tells the compiler a) int x should be available to this compilation unit, b) int x is not in this compilation unit and c) the linker should check it exists somewhere in all the units you've put together to form a library or program.
Conceptually, you're doing this all the time with forward-declarations of functions. There's just no way to forward declare a variable. In fact, you can do this with functions too and not bother r.e shared headers, although this is not really a good idea.
The other case is that "external variables" mean something external to a certain scope or module you have. I would check your assignment very carefully and if in doubt ask - whoever set it should be able to explain to you exactly what they mean.
An external variable is a variable with external linkage.
A variable with external linkage is a variable defined at file scope without the static keyword.
int bla = 0; // external variable
static int blop = 1; // non-external variable
int main(void)
{
return bla
}
Note that a variable declared with the extern keyword doesn't necessarily have external linkage. Like const does not mean constant in C, extern does not mean external.
People often use the word external to say that a variable is actually declared in the current translation unit but is defined in another translation unit.
The question was about plain c functions, not c++ static methods, as clarified in comments.
I understand what a static variable is, but what is a static function?
And why is it that if I declare a function, let's say void print_matrix, in let's say a.c (WITHOUT a.h) and include "a.c" - I get "print_matrix##....) already defined in a.obj", BUT if I declare it as static void print_matrix then it compiles?
UPDATE Just to clear things up - I know that including .c is bad, as many of you pointed out. I just do it to temporarily clear space in main.c until I have a better idea of how to group all those functions into proper .h and .c files. Just a temporary, quick solution.
static functions are functions that are only visible to other functions in the same file (more precisely the same translation unit).
EDIT: For those who thought, that the author of the questions meant a 'class method': As the question is tagged C he means a plain old C function. For (C++/Java/...) class methods, static means that this method can be called on the class itself, no instance of that class necessary.
There is a big difference between static functions in C and static member functions in C++. In C, a static function is not visible outside of its translation unit, which is the object file it is compiled into. In other words, making a function static limits its scope. You can think of a static function as being "private" to its *.c file (although that is not strictly correct).
In C++, "static" can also apply to member functions and data members of classes. A static data member is also called a "class variable", while a non-static data member is an "instance variable". This is Smalltalk terminology. This means that there is only one copy of a static data member shared by all objects of a class, while each object has its own copy of a non-static data member. So a static data member is essentially a global variable, that is a member of a class.
Non-static member functions can access all data members of the class: static and non-static. Static member functions can only operate on the static data members.
One way to think about this is that in C++ static data members and static member functions do not belong to any object, but to the entire class.
Minimal runnable multi-file scope example
Here I illustrate how static affects the scope of function definitions across multiple files.
a.c
#include <stdio.h>
/* Undefined behavior: already defined in main.
* Binutils 2.24 gives an error and refuses to link.
* https://stackoverflow.com/questions/27667277/why-does-borland-compile-with-multiple-definitions-of-same-object-in-different-c
*/
/*void f() { puts("a f"); }*/
/* OK: only declared, not defined. Will use the one in main. */
void f(void);
/* OK: only visible to this file. */
static void sf() { puts("a sf"); }
void a() {
f();
sf();
}
main.c
#include <stdio.h>
void a(void);
void f() { puts("main f"); }
static void sf() { puts("main sf"); }
void m() {
f();
sf();
}
int main() {
m();
a();
return 0;
}
GitHub upstream.
Compile and run:
gcc -c a.c -o a.o
gcc -c main.c -o main.o
gcc -o main main.o a.o
./main
Output:
main f
main sf
main f
a sf
Interpretation
there are two separate functions sf, one for each file
there is a single shared function f
As usual, the smaller the scope, the better, so always declare functions static if you can.
In C programming, files are often used to represent "classes", and static functions represent "private" methods of the class.
A common C pattern is to pass a this struct around as the first "method" argument, which is basically what C++ does under the hood.
What standards say about it
C99 N1256 draft 6.7.1 "Storage-class specifiers" says that static is a "storage-class specifier".
6.2.2/3 "Linkages of identifiers" says static implies internal linkage:
If the declaration of a file scope identifier for an object or a function contains the storage-class specifier static, the identifier has internal linkage.
and 6.2.2/2 says that internal linkage behaves like in our example:
In the set of translation units and libraries that constitutes an entire program, each declaration of a particular identifier with external linkage denotes the same object or function. Within one translation unit, each declaration of an identifier with internal linkage denotes the same object or function.
where "translation unit" is a source file after preprocessing.
How GCC implements it for ELF (Linux)?
With the STB_LOCAL binding.
If we compile:
int f() { return 0; }
static int sf() { return 0; }
and disassemble the symbol table with:
readelf -s main.o
the output contains:
Num: Value Size Type Bind Vis Ndx Name
5: 000000000000000b 11 FUNC LOCAL DEFAULT 1 sf
9: 0000000000000000 11 FUNC GLOBAL DEFAULT 1 f
so the binding is the only significant difference between them. Value is just their offset into the .bss section, so we expect it to differ.
STB_LOCAL is documented on the ELF spec at http://www.sco.com/developers/gabi/2003-12-17/ch4.symtab.html:
STB_LOCAL Local symbols are not visible outside the object file containing their definition. Local symbols of the same name may exist in multiple files without interfering with each other
which makes it a perfect choice to represent static.
Functions without static are STB_GLOBAL, and the spec says:
When the link editor combines several relocatable object files, it does not allow multiple definitions of STB_GLOBAL symbols with the same name.
which is coherent with the link errors on multiple non static definitions.
If we crank up the optimization with -O3, the sf symbol is removed entirely from the symbol table: it cannot be used from outside anyways. TODO why keep static functions on the symbol table at all when there is no optimization? Can they be used for anything?
See also
Same for variables: https://stackoverflow.com/a/14339047/895245
extern is the opposite of static, and functions are already extern by default: How do I use extern to share variables between source files?
C++ anonymous namespaces
In C++, you might want to use anonymous namespaces instead of static, which achieves a similar effect, but further hides type definitions: Unnamed/anonymous namespaces vs. static functions
The following is about plain C functions - in a C++ class the modifier 'static' has another meaning.
If you have just one file, this modifier makes absolutely no difference. The difference comes in bigger projects with multiple files:
In C, every "module" (a combination of sample.c and sample.h) is compiled independently and afterwards every of those compiled object files (sample.o) are linked together to an executable file by the linker.
Let's say you have several files that you include in your main file and two of them have a function that is only used internally for convenience called add(int a, b) - the compiler would easily create object files for those two modules, but the linker will throw an error, because it finds two functions with the same name and it does not know which one it should use (even if there's nothing to link, because they aren't used somewhere else but in it's own file).
This is why you make this function, which is only used internal, a static function. In this case the compiler does not create the typical "you can link this thing"-flag for the linker, so that the linker does not see this function and will not generate an error.
static function definitions will mark this symbol as internal. So it will not be visible for linking from outside, but only to functions in the same compilation unit, usually the same file.
First: It's generally a bad idea to include a .cpp file in another file - it leads to problems like this :-) The normal way is to create separate compilation units, and add a header file for the included file.
Secondly:
C++ has some confusing terminology here - I didn't know about it until pointed out in comments.
a) static functions - inherited from C, and what you are talking about here. Outside any class. A static function means that it isn't visible outside the current compilation unit - so in your case a.obj has a copy and your other code has an independent copy. (Bloating the final executable with multiple copies of the code).
b) static member function - what Object Orientation terms a static method. Lives inside a class. You call this with the class rather than through an object instance.
These two different static function definitions are completely different. Be careful - here be dragons.
"What is a “static” function in C?"
Let's start at the beginning.
It´s all based upon a thing called "linkage":
"An identifier declared in different scopes or in the same scope more than once can be made to refer to the same object or function by a process called linkage. 29)There are three kinds of linkage: external, internal, and none."
Source: C18, 6.2.2/1
"In the set of translation units and libraries that constitutes an entire program, each declaration of a particular identifier with external linkage denotes the same object or function. Within one translation unit, each declaration of an identifier with internal linkage denotes the same object or function. Each declaration of an identifier with no linkage denotes a unique entity."
Source: C18, 6.2.2/2
If a function is defined without a storage-class specifier, the function has external linkage by default:
"If the declaration of an identifier for a function has no storage-class specifier, its linkage is determined exactly as if it were declared with the storage-class specifier extern."
Source: C18, 6.2.2/5
That means that - if your program is contained of several translation units/source files (.c or .cpp) - the function is visible in all translation units/source files your program has.
This can be a problem in some cases. What if you want to use f.e. two different function (definitions), but with the same function name in two different contexts (actually the file-context).
In C and C++, the static storage-class qualifier applied to a function at file scope (not a static member function of a class in C++ or a function within another block) now comes to help and signifies that the respective function is only visible inside of the translation unit/source file it was defined in and not in the other TLUs/files.
"If the declaration of a file scope identifier for an object or a function contains the storage-class specifier static, the identifier has internal linkage. 30)"
A function declaration can contain the storage-class specifier static only if it is at file scope; see 6.7.1.
Source: C18, 6.2.2/3
Thus, A static function only makes sense, iff:
Your program is contained of several translation units/source files (.c or .cpp).
and
You want to limit the scope of a function to the file, in which the specific function is defined.
If not both of these requirements match, you don't need to wrap your head around about qualifying a function as static.
Side Notes:
As already mentioned, A static function has absolutely no difference at all between C and C++, as this is a feature C++ inherited from C.
It does not matter that in the C++ community, there is a heartbreaking debate about the depreciation of qualifying functions as static in comparison to the use of unnamed namespaces instead, first initialized by a misplaced paragraph in the C++03 standard, declaring the use of static functions as deprecated which soon was revised by the committee itself and removed in C++11.
This was subject to various SO questions:
Unnamed/anonymous namespaces vs. static functions
Superiority of unnamed namespace over static?
Why an unnamed namespace is a "superior" alternative to static?
Deprecation of the static keyword... no more?
In fact, it is not deprecated per C++ standard yet. Thus, the use of static functions is still legit. Even if unnamed namespaces have advantages, the discussion about using or not using static functions in C++ is subject to one´s one mind (opinion-based) and with that not suitable for this website.
A static function is one that can be called on the class itself, as opposed to an instance of the class.
For example a non-static would be:
Person* tom = new Person();
tom->setName("Tom");
This method works on an instance of the class, not the class itself. However you can have a static method that can work without having an instance. This is sometimes used in the Factory pattern:
Person* tom = Person::createNewPerson();
Minor nit: static functions are visible to a translation unit, which for most practical cases is the file the function is defined in. The error you are getting is commonly referred to as violation of the One Definition Rule.
The standard probably says something like:
"Every program shall contain exactly one definition of every noninline
function or object that is used in that program; no diagnostic
required."
That is the C way of looking at static functions. This is deprecated in C++ however.
In C++, additionally, you can declare member functions static. These are mostly metafunctions i.e. they do not describe/modify a particular object's behavior/state but act on the whole class itself. Also, this means that you do not need to create an object to call a static member function. Further, this also means, you only get access to static member variables from within such a function.
I'd add to Parrot's example the Singleton pattern which is based on this sort of a static member function to get/use a single object throughout the lifetime of a program.
The answer to static function depends on the language:
1) In languages without OOPS like C, it means that the function is accessible only within the file where its defined.
2)In languages with OOPS like C++ , it means that the function can be called directly on the class without creating an instance of it.
Since static function is only visible in this file.
Actually, compiler can do some optimization for you if you declare "static" to some function.
Here is a simple example.
main.c
#include <stdio.h>
static void test()
{
ghost(); // This is an unexist function.
}
int main()
{
int ret = 0;
#ifdef TEST
#else
test();
#endif
return (ret);
}
And compile with
gcc -o main main.c
You will see it failed. Because you even not implement ghost() function.
But what if we use following command.
gcc -DTEST -O2 -o main main.c
It success, and this program can be execute normally.
Why? There are 3 key points.
-O2 : Compiler optimization level at least 2.
-DTEST : Define TEST, so test() will not be called.
Defined "static" to test().
Only if these 3 conditions are all true, you can pass compilation.
Because of this "static" declaration, compiler can confirm that test() will NEVER be called in other file. Your compiler can remove test() when compiling. Since we don't need test(), it does not matter whether ghost() is defined or implemented.