An explanation of the role of extern

extern effect 1: declaring external variables
Modern compilers are generally compiled by file, so at compile time, the global variables defined in each file are
Transparent to each other, that is, at compile time, the visible domain of the global variable is limited to the inside of the file.

Example 1:
Create a project that contains A.cpp and B.cpp two simple C + + source files:
A.cpp:
int IRI;
int main ()
{
//.....
}

B.cpp
int IRI;

GCC a.cpp-c
GCC b.cpp-c
Compile out A.O, b.o all have no problem.
But when GCC a.o b.o-o test,
MAIN.O: (. bss+0x0): Multiple definition of ' IRI '
B.O: (. bss+0x0): defined here
Error: Redefining.
(But there was a very unexpected discovery: when the same code, the use of A.C B.C.) and compile with GCC, unexpectedly does not report the redefinition of the error, very do not understand what is going on. )
That is, in the compile phase, the global variables defined in each file are transparent to each other, and when you compile a, you do not perceive the I in B, and likewise, when you compile B, you do not perceive that a is defined by I.
But in the link phase, the contents of each file are "integrated", so if you have the same global variable name defined in some files, there will be an error at this point, which is the duplicate-defined error indicated above. Therefore, the names of the global variables defined in each file cannot be the same.

However, if you define IRI in the B.cpp in the following ways, use it directly in A.cpp. You cannot pass when compiling A.cpp.
A.cpp
int main ()
{
iri=64;
}

B.cpp
int IRI;

GCC a.cpp-c
Wasn't declared in this scope.

Because the compiler compiles by file, it is not known that IRI is defined in B.cpp when compiling A.cpp.
That is, the visibility of the global variables defined in the file extends to the entire program after the link is complete, while at compile time their visibility is still limited to their respective files.
The solution is as follows:
The compiler's gaze is not long enough for the compiler to realize that a variable symbol, although not defined in this file, may be defined in other files.
Although the compiler is not far-sighted, we can give it a hint to help solve the problem that appears above. This is the role of extern.
the principle of extern is simply to tell the compiler: "The file you are compiling now has an identifier that is not defined in this file, but it is a global variable defined in another file that you want to release." "
A.cpp:
extern int IRI;
int main ()
{
IRI = 64;
//.....
}

B.cpp
int IRI;
This will enable the compilation to pass.
extern int IRI; Does not allocate space, just notifies the compiler that the IRI has been defined in other files.


extern action 2: Calling C-way compiled functions in C + + files
C-way Compilation and C + + method compilation
New features, such as overloading, are added to the c,c++. So there's a big difference between the way a global variable and a function name are compiled.
int A;
int Functiona ();
For C-Way compilation:
int a;=> _a
int Functiona (); => _functiona
For C + + method compilation:
int A; =>xx@xxx@a
int Functiona (); => Xx@xx@functiona
As you can see, because you want to support overloading, the generated global variable names and function names are much more complex under C + + compilation. The addition of an underscore is different from the C-way compilation.
So there are several things:
Example 2:c++ calls a global variable defined by C + +
A.cpp:
extern int IRI;
int main ()
{
IRI = 64;
//.....
}
B.cpp
int IRI;
GCC a.cpp-c
GCC b.cpp-c
GCC A.O b.o-o Test
Then it's okay to compile the link.

Example 3:c++ calling global variables defined by C
A.cpp:
extern int IRI;
int main ()
{
IRI = 64;
//.....
}
B.c
int IRI;
There is no problem at compile time,
GCC a.cpp-c
GCC b.c-c
But when linking, GCC b.o a.o-o test
It will be reported that the IRI is not defined. Why, then?
Because GCC sees A.cpp, compile with C + +, see B.C, use C method to compile.
So the iri=>xxx@xxx_iri; in the A.cpp
and B.C in the Iri=〉_iri;
So in the link, A.cpp want to find Xxx@xxx_iri, of course, can not find. So you need to tell the compiler that IRI is compiled using the C method.
A.cpp:
extern "C"
{
int IRI;
}
int main ()
{IRI = 64;
//.....
}
B.c
int IRI;
In this way, when compiling A.cpp, the compiler knows that IRI is compiled in C. You will use _iri. So the _iri provided by B.C can be found by A.cpp.

Example 4:c++ calls C-defined function
A.cpp
extern int Functiona ();

int main ()
{
Functiona ();
}

B.c
int Functiona ()
{
//....
}
GCC a.cpp-c
GCC b.c-c
No problem at all. But again, GCC a.o b.o-o test
The error is not found Functiona ();
This is because GCC compiles A.cpp as C + +, B.C is compiled in C mode.
So Functiona in the B.C: _functiona. In A.cpp: Xx@xxx_functiona
So A.cpp can't find xx@xx_function when linking.
It is then necessary to notify the compiler that the Functiona () is compiled with the C-way name.
A.cpp
extern "C"
{
int Functiona ();
}
int main ()
{
Functiona ();
}

B.c
int Functiona ()
{
//....
}
As a result, the compilation link can be passed.

Summarize:

extern "C"
{
Functiona ();
}//is more than just a declaration, and it says: This function is compiled in C. So there's no need to be extern again.
extern "C"
{
extern Functiona ();
}//this doesn't make much sense.