Extern 作用及使用（合转）

1.extern作用详解

extern 作用1：声明外部变量
现代编译器一般采用按文件编译的方式，因此在编译时，各个文件中定义的全局变量是
互相透明的，也就是说，在编译时，全局变量的可见域限制在文件内部。

例1：
创建一个工程，里面含有A.cpp和B.cpp两个简单的C++源文件：
//A.cpp:
int iRI;
int main()
{
//.....
}

//B.cpp
int iRI;

gcc A.cpp -c
gcc B.cpp -c
编译出A.o, B.o都没有问题。
但当gcc A.o B.o -o test时，
main.o:(.bss+0x0): multiple definition of `iRI'
b.o:(.bss+0x0): first defined here
报错：重定义。
（但有个非常意外的发现：当同样的代码，使用A.c B.c.并使用gcc编译时，竟然不会报重定义的错误，非常不明白是怎么回事。）
这就是说，在编译阶段，各个文件中定义的全局变量相互是透明的，编译A时觉察不到B中也定义了i，同样，编译B时觉察不到A中也定义了i。
但是到了链接阶段，要将各个文件的内容“合为一体”，因此，如果某些文件中定义的全局变量名相同的话，在这个时候就会出现错误，也就是上面提示的重复定义的错误。因此，各个文件中定义的全局变量名不可相同。

但如果用下列方式：在B.cpp中定义iRI;在A.cpp中直接使用。则编译A.cpp时就无法通过。
//A.cpp
int main()
{
iRI=64;
}

//B.cpp
int iRI;

gcc A.cpp -c
was not declared in this scope.

因为编译器按照文件方式编译，所以编译A.cpp时，并不知道B.cpp中定义了iRI。
也就是说：文件中定义的全局变量的可见性扩展到整个程序是在链接完成之后，而在编译阶段，他们的可见性仍局限于各自的文件。
解决方案如下：
编译器的目光不够长远，编译器没有能够意识到，某个变量符号虽然不是本文件定义的，但是它可能是在其它的文件中定义的。
虽然编译器不够远见，但是我们可以给它提示，帮助它来解决上面出现的问题。这就是extern的作用了。
extern的原理很简单，就是告诉编译器：“你现在编译的文件中，有一个标识符虽然没有在本文件中定义，但是它是在别的文件中定义的全局变量，你要放行！”
//A.cpp:
extern int iRI;
int main()
{
iRI = 64;
//.....
}

//B.cpp
int iRI;
这样编译就能够通过。
extern int iRI; //并未分配空间，只是通知编译器，在其它文件定义过iRI。

extern 作用2：在C++文件中调用C方式编译的函数
C方式编译和C++方式编译
相对于C，C++中新增了诸如重载等新特性。所以全局变量和函数名编译后的命名方式有很大区别。
int a;
int functionA();
对于C方式编译：
int a;=> _a
int functionA(); => _functionA
对于C++方式编译：
int a; =>xx@xxx@a
int functionA(); => xx@xx@functionA
可以看出，因为要支持重载，所以C++方式编译下，生成的全局变量名和函数名复杂很多。与C方式编译的加一个下划线不同。
于是就有下面几种情况：
例2：C++调用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
那么在编译链接时都没问题。

例3：C++调用C定义的全局变量
//A.cpp:
extern int iRI;
int main()
{
iRI = 64;
//.....
}
//B.c
int iRI;
编译时没有问题，
gcc A.cpp -c
gcc B.c -c
但链接时，gcc B.o A.o -o test
则会报iRI没有定义。为什么呢？
因为gcc看到A.cpp，就使用C++方式编译，看到B.c，就使用C方式编译。
所以在A.cpp中的iRI=>XXX@XXX_iRI;
而B.c中iRI=〉_iRI;
所以在链接时，A.cpp想找到XXX@XXX_iRI，当然找不到。所以就需要告诉编译器，iRI是使用C方式编译的。
//A.cpp:
extern "C"
{
int iRI;
}
int main()
{ iRI = 64;
//.....
}
//B.c
int iRI;
这样，当编译A.cpp时，编译器就知道iRI为C方式编译的。就会使用 _iRI。这样B.c提供的_iRI就可以被A.cpp找到了。

例4：C++调用C定义的function
//A.cpp
extern int functionA();

int main()
{
functionA();
}

//B.c
int functionA()
{
//....
}
gcc A.cpp -c
gcc B.c -c
都没有问题。但同样的，gcc A.o B.o -o test
则报错，找不到functionA();
这是因为gcc将A.cpp认为是C++方式编译，B.c是C方式编译。
所以functionA在B.c中为：_functionA. 在A.cpp中为：XX@XXX_functionA
所以在链接时A.cpp找不到XX@XX_function.
于是需要通知编译器，functionA()是C方式编译命名的。
//A.cpp
extern "C"
{
int functionA();
}
int main()
{
functionA();
}

//B.c
int functionA()
{
//....
}
于是，编译链接都可以通过。

总结：

extern "C"
{
functionA();
}//不止是声明，并且还指出：这个function请用C方式编译。所以不需要再次extern.
extern"C"
{
extern functionA();
}//这样做没什么太大意义。
————————————————
版权声明：本文为CSDN博主「Vincent_Song」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/songjinshi/article/details/6785267

2. C++中extern关键字用法小结

总结C++中关于extern关键字的用法。

1.变量的生明和定义中

C++语言支持分离式编译机制，该机制允许将程序分割为若干个文件，每个文件可被独立编译。为了将程序分为许多文件，则需要在文件中共享代码，例如一个文件的代码可能需要另一个文件中中定义的变量。

为了支持分离式编译，C++允许将声明和定义分离开来。变量的声明规定了变量的类型和名字，即使一个名字为程序所知，一个文件如果想使用别处定义的名字则必须包含对那个名字的声明。定义则负责创建与名字关联的实体，定义还申请存储空间。

如果想声明一个变量而非定义它，就在变量名前添加extern关键字，而且不要显式地初始化变量：

extern int i;  //声明i而非定义
int j;         //声明并定义i

但我们也可以给由extern关键字标记的变量赋一个初始值，但这样就不是一个声明了，而是一个定义：

extern int v = 2;
int v = 2;     //这两个语句效果完全一样，都是v的定义

注意： 变量能且只能被定义一次，但是可以被声明多次。

2.在多个文件中共享const对象

默认情况下，一个const对象仅在本文件内有效，如果多个文件中出现了同名的const变量时，其实等同于在不同的文件中分别定义了独立的变量。

某些时候有这样一种const变量，它的初始值不是一个常量表达式，但又确实有必要在文件间共享。这种情况下，我们不希望编译器为每个文件分别生成独立的变量。我们想让这类const对象像其他非常量对象一样工作，也就是说，只在一个文件中定义const，而在其他多个文件中声明并使用它。

方法是对于const变量不管是声明还是定义都添加extern关键字，这样只需要定义一次就可以了：

//file1.cpp定义并初始化和一个常量，该常量能被其他文件访问
extern const int bufferSize = function();
//file1.h头文件
extern const int bufferSize; //与file1.cpp中定义的是同一个

file1.h头文件中的声明也由extern做了限定，其作用是指明bufferSize并非本文件独有，它的定义将出现在别处。

3.模板的控制实例化

当两个或者多个独立编译的源文件中使用了相同的模板并且提供了相同的模板参数时，每个文件中都会有该模板的一个实例。

在大系统中，在多个文件中实例化相同的模板的额外开销可能非常严重，在C++11新标准中，我们可以通过显式实例化来避免这种开销。一个显式实例化具有如下形式：

extern template declaration; //实例化声明
template declaration;        //实例化定义

declaration是一个类或函数的声明，其中所有的模板参数都已经被替换成为模板实参。例如：

extern template class vec<string>;       //声明
template int sum(const int, const int);  //定义

当编译器遇到extern模板声明时，它不会在本文件中生成实例化代码，将一个实例化声明为extern就表示承诺在程序的其他位置有该实例化的一个非extern定义。对于一个给定的实例化版本，可能有多个extern声明，但必须只有一个定义。

由于编译器在使用一个模板时自动对其实例化，因此extern声明必须出现在任何使用此实例化吧版本的代码之前。

由于以上讨论可知：extern一般是使用在多文件之间需要共享某些代码时。

3. What is the effect of extern "C" in C++? - Stack Overflow

extern "C" makes a function-name in C++ have C linkage (compiler does not mangle the name) so that client C code can link to (use) your function using a C compatible header file that contains just the declaration of your function. Your function definition is contained in a binary format (that was compiled by your C++ compiler) that the client C linker will then link to using the C name.

Since C++ has overloading of function names and C does not, the C++ compiler cannot just use the function name as a unique id to link to, so it mangles the name by adding information about the arguments. A C compiler does not need to mangle the name since you can not overload function names in C. When you state that a function has extern "C" linkage in C++, the C++ compiler does not add argument/parameter type information to the name used for linkage.

Just so you know, you can specify extern "C" linkage to each individual declaration/definition explicitly or use a block to group a sequence of declarations/definitions to have a certain linkage:

extern "C" void foo(int);
extern "C"
{
   void g(char);
   int i;
}

If you care about the technicalities, they are listed in section 7.5 of the C++03 standard, here is a brief summary (with emphasis on extern "C"):

• extern "C" is a linkage-specification
• Every compiler is required to provide "C" linkage
• A linkage specification shall occur only in namespace scope
• All function types, function names and variable names have a language linkage See Richard's Comment: Only function names and variable names with external linkage have a language linkage
• Two function types with distinct language linkages are distinct types even if otherwise identical
• Linkage specs nest, inner one determines the final linkage
• extern "C" is ignored for class members
• At most one function with a particular name can have "C" linkage (regardless of namespace)
• extern "C" forces a function to have external linkage (cannot make it static) See Richard's comment: static inside extern "C" is valid; an entity so declared has internal linkage, and so does not have a language linkage
• Linkage from C++ to objects defined in other languages and to objects defined in C++ from other languages is implementation-defined and language-dependent. Only where the object layout strategies of two language implementations are similar enough can such linkage be achieved