[C++]Linkage

Compile : 将以文本形式存在的源代码翻译为机器语言形式的目标文件

cc1.cpp --> cc1.o

cc2.cpp --> cc2.o

cc3.cpp --> cc3.o

Link:

   link 1.o 2.o 3.o -o a.out

1. Translation unit (编译单元) TU: one source file and its included header fileds
1. 各个编译单元之间是互相不可知的
2. One Definition Rule : ODR

extern : 

1. extern int value; //decleared as external means the definition is in another translation unit  
2. this .o file will put " value " to unrresolved symbol table  (symbol)
3. the .o file who offers "value"'s definition should use export to put it into export symbol table

static:

1. static int value; //static before global function or variabel  means this function/variable is only unsed in this TU
2. 如果一个变量是属于内部连接的话，那么它在每一个 TU 里面都是独一无二的
1. 
   
2. const object (如 const int* 、const double 等等)
3. constexpr objects (如 constexpr char*)
4. typedefs
5. static objects in namespace scope (如全局 static int age)

 for function and variable, the default is external link, const variable is internal link by default

https://www.cnblogs.com/elwinch/articles/2201091.html:

详解link
    有些人写C/C++(以下假定为C++)程序，对unresolved external link或者duplicated external simbol的错误信息不知所措（因为这样的错误信息不能定位到某一行）。或者对语言的一些部分不知道为什么要（或者不要）这样那样设计。了解本文之后，或许会有一些答案。
    首先看看我们是如何写一个程序的。如果你在使用某种IDE（Visual Studio，Elicpse，Dev C++等），你可能不会发现程序是如何组织起来的（很多人因此而反对初学者使用IDE）。因为使用IDE，你所做的事情，就是在一个项目里新建一系列的.cpp和.h文件，编写好之后在菜单里点击“编译”，就万事大吉了。但其实以前，程序员写程序不是这样的。他们首先要打开一个编辑器，像编写文本文件一样的写好代码，然后在命令行下敲
   cc 1.cpp -o 1.o
   cc 2.cpp -o 2.o
   cc 3.cpp -o 3.o
这里cc代表某个C/C++编译器，后面紧跟着要编译的cpp文件，并且以-o指定要输出的文件（请原谅我没有使用任何一个流行编译器作为例子）。这样当前目录下就会出现：
   1.o 2.o 3.o
最后，程序员还要键入
   link 1.o 2.o 3.o -o a.out
来生成最终的可执行文件a.out。现在的IDE，其实也同样遵照着这个步骤，只不过把一切都自动化了。
    让我们来分析上面的过程，看看能发现什么。
    首先，对源代码进行编译，是对各个cpp文件单独进行的。对于每一次编译，如果排除在cpp文件里include别的cpp文件的情况（这是C++代码编写中极其错误的写法），那么编译器仅仅知道当前要编译的那一个cpp文件，对其他的cpp文件的存在完全不知情。
    其次，每个cpp文件编译后，产生的.o文件，要被一个链接器(link)所读入，才能最终生成可执行文件。
    好了，有了这些感性认识之后，让我们来看看C/C++程序是如何组织的。
   
    首先要知道一些概念：
    编译：编译器对源代码进行编译，是将以文本形式存在的源代码翻译为机器语言形式的目标文件的过程。
    编译单元：对于C++来说，每一个cpp文件就是一个编译单元。从之前的编译过程的演示可以看出，各个编译单元之间是互相不可知的。
    目标文件：由编译所生成的文件，以机器码的形式包含了编译单元里所有的代码和数据，以及一些其他的信息。
   
    下面我们具体看看编译的过程。我们跳过语法分析等，直接来到目标文件的生成。假设我们有一个1.cpp文件
    int n = 1;

   void f()
    {
       ++n;
    }

    它编译出来的目标文件1.o就会有一个区域（假定名称为2进制段），包含了以上数据／函数，其中有n, f，以文件偏移量的形式给出很可能就是：
   偏移量   内容   长度
   0x000   n   4
   0x004   f    ??
    注意：这仅仅是猜测，不代表目标文件的真实布局。目标文件的各个数据不一定连续，也不一定按照这个顺序，当然也不一定从0x000开始。
    现在我们看看从0x004开始f函数的内容（在0x86平台下的猜测）：
   0x004 inc DWORD PTR [0x000]
   0x00? ret
    注意n++已经被翻译为：inc DWORD PTR [0x000]，也就是把本单元0x000位置上的一个DWORD(4字节)加1。
   
    下面如果有另一个2.cpp，如下
   extern int n;
   void g()
   {
       ++n;
   }
    那么它的目标文件2.o的2进制段就应该是
   偏移量   内容   长度
   0x000   g    ??
    为什么这里没有n的空间（也就是n的定义），因为n被声明为extern，表明n的定义在别的编译单元里。别忘了编译的时候是不可能知道别的编译单元的情况的，故编译器不知道n究竟在何处，所以这个时候g的二进制代码里没有办法填写inc DWORD PTR [???]中的？？？部分。怎么办呢？这个工作就只能交给后来的链接器去处理。为了让链接器知道哪些地方的地址是没有填好的，所以目标文件还要有一个“未解决符号表”，也就是unresolved symbol table. 同样,提供n的定义的目标文件(也就是1.o)也要提供一个“导出符号表”，export symbol table, 来告诉链接器自己可以提供哪些地址。
    让我们理一下思路：现在我们知道，每一个目标文件，除了拥有自己的数据和二进制代码之外，还要至少提供2个表：未解决符号表和导出符号表，分别告诉链接器自己需要什么和能够提供什么。下面的问题是，如何在2个表之间建立对应关系。这里就有一个新的概念：符号。在C/C++中，每一个变量和函数都有自己的符号。例如变量n的符号就是“n”。函数的符号要更加复杂，它需要结合函数名及其参数和调用惯例等，得到一个唯一的字符串。f的符号可能就是"_f"（根据不同编译器可以有变化）。
    所以，1.o的导出符号表就是
   符号   地址
   n   0x000
   _f   0x004
    而未解决符号表为空
    2.o的导出符号表为
   符号   地址
   _g   0x000
    未解决符号表为
   符号   地址   
   n   0x001   
    这里0x001为从0x000开始的inc DWORD PTR [???]的二进制编码中存储???的起始地址(这里假设inc的机器码的第2－5字节为要+1的绝对地址，需要知道确切情况可查手册)。这个表告诉链接器，在本编译单元0x001的位置上有一个地址，该地址值不明，但是具有符号n。
    链接的时候，链接器在2.o里发现了未解决符号n，那么在查找所有编译单元的时候，在1.o中发现了导出符号n，那么链接器就会将n的地址0x000填写到2.o的0x001的位置上。
    “打住”，可能你就会跳出来指责我了。如果这样做得话，岂不是g的内容就会变成inc DWORD PTR [0x000]，按照之前的理解，这是将本单元的0x000地址的4字节加1，而不是将1.o的对应位置加1。是的，因为每个编译单元的地址都是从0开始的，所以最终拼接起来的时候地址会重复。所以链接器会在拼接的时候对各个单元的地址进行调整。这个例子中，假设2.o的0x00000000地址被定位在可执行文件的0x00001000上，而1.o的0x00000000地址被定位在可执行文件的0x00002000上，那么实际上对链接器来说，1.o的导出符号表其实
   符号   地址
   n   0x000 + 0x2000
   _f   0x004 + 0x2000
    而未解决符号表为空
    2.o的导出符号表为
   符号   地址
   _g   0x000 + 0x1000
    未解决符号表为
   符号   地址           
   n   0x001 + 0x1000
所以最终g的代码会变为inc DWORD PTR [0x000 + 0x2000]。
    最后还有一个漏洞，既然最后n的地址变为0x2000了，那么以前f的代码inc DWORD PTR [0x000]就是错误的了。所以目标文件为此还要提供一个表，叫做地址重定向表address redirect table。
    对于1.o来说，它的重定向表为
   地址
   0x005
    这个表不需要符号，当链接器处理这个表的时候，发现地址为0x005的位置上有一个地址需要重定向，那么直接在以0x005开始的4个字节上加上0x2000就可以了。
    让我们总结一下：编译器把一个cpp编译为目标文件的时候，除了要在目标文件里写入cpp里包含的数据和代码，还要至少提供3个表：未解决符号表，导出符号表和地址重定向表。
    未解决符号表提供了所有在该编译单元里引用但是定义并不在本编译单元里的符号及其出现的地址。
    导出符号表提供了本编译单元具有定义，并且愿意提供给其他编译单元使用的符号及其地址。
    地址重定向表提供了本编译单元所有对自身地址的引用的记录。

    链接器进行链接的时候，首先决定各个目标文件在最终可执行文件里的位置。然后访问所有目标文件的地址重定向表，对其中记录的地址进行重定向（即加上该编译单元实际在可执行文件里的起始地址）。然后遍历所有目标文件的未解决符号表，并且在所有的导出符号表里查找匹配的符号，并在未解决符号表中所记录的位置上填写实际的地址（也要加上拥有该符号定义的编译单元实际在可执行文件里的起始地址）。最后把所有的目标文件的内容写在各自的位置上，再作一些别的工作，一个可执行文件就出炉了。
    最终link 1.o 2.o .... 所生成的可执行文件大概是
   0x00000000 ????（别的一些信息）
   ....
   0x00001000 inc DWORD PTR [0x00002000]             //这里是2.o的开始，也就是g的定义
   0x00001005 ret                                 //假设inc为5个字节，这里是g的结尾
   ....
   0x00002000 0x00000001                          //这里是1.o的开始，也是n的定义（初始化为1）
   0x00002004 inc DWORD PTR [0x00002000]      //这里是f的开始
   0x00002009 ret                                 //假设inc为5个字节，这里是f的结尾
   ...
   ...
    实际链接的时候更为复杂，因为实际的目标文件里把数据／代码分为好几个区，重定向等要按区进行，但原理是一样的。


    现在我们可以来看看几个经典的链接错误了：
   unresolved external link..
   这个很显然，是链接器发现一个未解决符号，但是在导出符号表里没有找到对应的項。
   解决方案么，当然就是在某个编译单元里提供这个符号的定义就行了。（注意，这个符号可以是一个变量，也可以是一个函数），也可以看看是不是有什么该链接的文件没有链接
   duplicated external simbols...
   这个则是导出符号表里出现了重复项，因此链接器无法确定应该使用哪一个。这可能是使用了重复的名称，也可能有别的原因。


    我们再来看看C/C++语言里针对这一些而提供的特性：
   extern: 这是告诉编译器，这个符号在别的编译单元里定义，也就是要把这个符号放到未解决符号表里去;（外部链接）
   
   static: 如果该关键字位于全局函数或者变量的声明的前面，表明该编译单元不导出这个函数／变量的符号。因此无法在别的编译单元里使用。（内部链接）。如果是static局部变量，则该变量的存储方式和全局变量一样，但是仍然不导出符号。
   
   默认链接属性：对于函数和变量，模认外部链接，对于const变量，默认内部链接。 （可以通过添加extern和static改变链接属性）

   外部链接的利弊：外部链接的符号，可以在整个程序范围内使用（因为导出了符号）。但是同时要求其他的编译单元不能导出相同的符号（不然就是duplicated external simbols)

   内部链接的利弊：内部链接的符号，不能在别的编译单元内使用。但是不同的编译单元可以拥有同样名称的内部链接符号。

   为什么头文件里一般只可以有声明不能有定义：头文件可以被多个编译单元包含，如果头文件里有定义，那么每个包含这个头文件的编译单元就都会对同一个符号进行定义，如果该符号为外部链接，则会导致duplicated external simbols。因此如果头文件里要定义，必须保证定义的符号只能具有内部链接。

   为什么常量默认为内部链接，而变量不是：
       这就是为了能够在头文件里如const int n = 0这样的定义常量。由于常量是只读的，因此即使每个编译单元都拥有一份定义也没有关系。如果一个定义于头文件里的变量拥有内部链接，那么如果出现多个编译单元都定义该变量，则其中一个编译单元对该变量进行修改，不会影响其他单元的同一变量，会产生意想不到的后果。

   为什么函数默认是外部链接：
       虽然函数是只读的，但是和变量不同，函数在代码编写的时候非常容易变化，如果函数默认具有内部链接，则人们会倾向于把函数定义在头文件里，那么一旦函数被修改，所有包含了该头文件的编译单元都要被重新编译。另外，函数里定义的静态局部变量也将被定义在头文件里。

   为什么类的静态变量不可以就地初始化：

所谓就地初始化就是类似于这样的情况：
       class A
       {
           static char msg[] = "aha";
       };
不允许这样做得原因是，由于class的声明通常是在头文件里，如果允许这样做，其实就相当于在头文件里定义了一个非const变量。

   在C++里，头文件定义一个const对象会怎么样：
       一般不会怎么样，这个和C里的在头文件里定义const int一样，每一个包含了这个头文件的编译单元都会定义这个对象。但由于该对象是const的，所以没什么影响。但是：有2种情况可能破坏这个局面：
       1。如果涉及到对这个const对象取地址并且依赖于这个地址的唯一性，那么在不同的编译单元里，取到的地址可以不同。（但一般很少这么做）
       2。如果这个对象具有mutable的变量，某个编译单元对其进行修改，则同样不会影响到别的编译单元。

   为什么类的静态常量也不可以就地初始化：
       因为这相当于在头文件里定义了const对象。作为例外，int/char等可以进行就地初始化，是因为这些变量可以直接被优化为立即数，就和宏一样。

   内联函数：
       C++里的内联函数由于类似于一个宏，因此不存在链接属性问题。

   为什么公共使用的内联函数要定义于头文件里：
       因为编译时编译单元之间互相不知道，如果内联函数被定义于.cpp文件中，编译其他使用该函数的编译单元的时候没有办法找到函数的定义，因此无法对函数进行展开。所以说如果内联函数定义于.cpp文件里，那么就只有这个cpp文件可以是用这个函数。

   头文件里内联函数被拒绝会怎样：
       如果定义于头文件里的内联函数被拒绝，那么编译器会自动在每个包含了该头文件的编译单元里定义这个函数并且不导出符号。

   如果被拒绝的内联函数里定义了静态局部变量，这个变量会被定义于何处：
       早期的编译器会在每个编译单元里定义一个，并因此产生错误的结果，较新的编译器会解决这个问题，手段未知。

   为什么export关键字没人实现：
       export要求编译器跨编译单元查找函数定义，使得编译器实现非常困难。

https://blog.csdn.net/w2865673691/article/details/13018563

extern是C/C++语言中表明函数和全局变量作用范围（可见性）的关键字。它告诉编译器，其声明的函数和变量可以在本模块或其它模块中使用。extern可以置于变量或者函数前，以标示变量或者函数的定义在别的文件中，提示编译器遇到此变量和函数时在其他模块中寻找其定义。另外，extern也可用来进行链接指定。

C/C++的编译与运行

要想彻底明白extern是怎么回事，首先应该知道C＋＋生成可执行代码的过程。C＋＋生成可执行代码的全过程要经过几个步骤，依次是：

预处理（处理宏定义、头文件等）===>>>编译、优化（这里生成的是中间代码，比如说用汇编代码当中间代码，那么生成的就是汇编语言组成的汇编程序）===>>>汇编（汇编后生存机器语言代码）===>>>链接（生成可执行文件） ，详细如下：

1、预处理：预处理器（preprocessor）是一个简单的程序，它用程序员（利用预处理器指令）定义好的模式代替源代码中的模式（删除注释、包含其他文件以及执行宏），预处理后生成中间文件.i（文本）。

2、编译、优化：接下来对于.i文件进行语法分析。编译器把源代码分解成小的单元并把它们按树形结构组织起来。表达式中“A + B”中的“A”、“+”和“B”就是语法分析树的叶子节点。语法分析树建立后有时会根据用户定义，使用全局优化器（global optimizer）来生成更短、更快的代码。优代完成之后，还需要使用代码生成器（code generator）遍历语法分析树，把树的每个节点转化成汇编语言，这个期间保存为中间文件.s（汇编语言 文本）。之后根据用户定义可以使用窥孔优化器（peephole optimizer）从相邻一段代码中查找冗余汇编语句。

3、汇编： 接下来使用汇编器将汇编源文件翻译成对应的机器指令，而且还写入一些东西与机器指令打包成可重新定位目标程序格式的文件，生成中间文件.o（目标文件 二进制）。

4、链接：最后使用连接器（linker）把一组目标模块连接成为一个可执行程序（最终文件.exe），简单的讲，把目标的库文件和所需要的引用的静、动态链接库进行链接，即需要把其他静态库合成到可执行文件中，转换相应的符号引用为地址，然后确保所引用的其他动态链接库的符号存在。此外，链接器还要完成程序中各目标文件的地址空间的组织，这可能设计重定位工作。大多数现代操作系统都提供静态链接和动态链接两种形式。

extern为何而生

现在以外部变量的声明作为线索来探讨一下extern到底是为何而生的以及它有何编译、链接有什么关系。

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

下面举一个简单的例子，创建一个工程，里面含有A.cpp和B.cpp两个简单的C++源文件：

//A.cpp

int i;

int main()

{

}

//B.cpp

int i;

这两个文件极为简单，在A.cpp中我们定义了一个全局变量i，在B中我们也定义了一个全局变量i。我们对A和B分别编译，都可以正常通过编译，但是进行链接的时候，却出现了错误，错误提示如下：

Linking...

B.obj : error LNK2005: "int i" (?i@@3HA) already defined in A.obj

Debug/A.exe : fatal error LNK1169: one or more multiply defined symbols found

Error executing link.exe.

A.exe - 2 error(s), 0 warning(s)

这就是说，在编译阶段，各个文件中定义的全局变量相互是不透明的，编译A时觉察不到B中也定义了i，同样，编译B时觉察不到A中也定义了i。但是到了链接阶段，要将各个文件的内容“合为一体”，因此，如果某些文件中定义的全局变量名相同的话，在这个时候就会出现错误，也就是上面提示的重复定义的错误。因此，各个文件中定义的全局变量名不可相同。

在链接阶段，各个文件的内容（实际是编译产生的obj文件）是被合并到一起的，因而，定义于某文件内的全局变量，在链接完成后，它的可见范围被扩大到了整个程序。

这样一来，按道理说，一个文件中定义的全局变量，可以在整个程序的任何地方被使用，然而把上面代码修改为如下所示，却依然编译报错：

//A.cpp

int main()

{

    i = 100; //试图使用B中定义的全局变量

}

//B.cpp

int i;

编译结果如下：

Compiling...

A.cpp

C:\Documents and Settings\wangjian\桌面\try extern\A.cpp(5) : error C2065: 'i' : undeclared identifier

Error executingcl.exe.

A.obj - 1 error(s), 0 warning(s)

其实出现这个错误是意料之中的，因为文件中定义的全局变量的可见性扩展到整个程序是在链接完成之后，而在编译阶段，他们的可见性仍局限于各自的文件。编译器的目光不够长远，编译器没有能够意识到，某个变量符号虽然不是本文件定义的，但是它可能是在其它的文件中定义的。

虽然编译器不够有远见，但是我们可以给它提示，帮助它来解决上面出现的问题。这就是extern的作用了。extern的原理很简单，就是告诉编译器：“你现在编译的文件中，有一个标识符虽然没有在本文件中定义，但是它是在别的文件中定义的全局变量，你可以使用。”于是上面代码可以修改为：

//A.cpp

extern int i;

int main()

{

    i = 100; //试图使用B中定义的全局变量

}

//B.cpp

int i;

顺利通过编译，链接。

extern修饰函数声明

其实上面的模块同时介绍了extern修饰外部变量的声明，从本质上来讲，变量和函数没有区别。函数名是指向函数二进制块开头处的指针。如果文件a.c需要引用b.c中的函数，比如在b.c中原型是int fun(int mu)，那么就可以在a.c中声明extern int fun（int mu），然后就能使用fun来做任何事情。就像变量的声明一样，extern int fun（int mu）可以放在a.c中任何地方，而不一定非要放在a.c的文件作用域的范围中。

对其他模块中函数的引用，最常用的方法是包含这些函数声明的头文件。使用extern和包含头文件来引用函数有什么区别呢？extern的引用方式比包含头文件要简洁得多！extern的使用方法是直接了当的，想引用哪个函数就用extern声明哪个函数。这大概是KISS原则的一种体现吧！这样做的一个明显的好处是，会加速程序的编译（确切的说是预处理）的过程，节省时间。在大型C程序编译过程中，这种差异是非常明显的。

在下面的模块中还要介绍更多的extern与函数之间的实例。

extern "C" 

C++语言的创建初衷是“a better C”，但是这并不意味着C++中类似C语言的全局变量和函数所采用的编译和连接方式与C语言完全相同。作为一种欲与C兼容的语言，C++保留了一部分过程式语言的特点（被世人称为“不彻底地面向对象”），因而它可以定义不属于任何类的全局变量和函数。但是，C++毕竟是一种面向对象的程序设计语言，为了支持函数的重载，C++对全局函数的处理方式与C有明显的不同，先来一个例子：

#ifndef __INCvxWorksh

#define __INCvxWorksh

#ifdef __cplusplus

extern "C" {

#endif

/*...*/

#ifdef __cplusplus

}

#endif

#endif /* __INCvxWorksh */

显然，头文件中的编译宏“#ifndef __INCvxWorksh、#define __INCvxWorksh、#endif” 的作用是防止该头文件被重复引用。下面着重讨论一下extern "C"。

作为一种面向对象的语言，C++支持函数重载，而过程式语言C则不支持。函数被C++编译后在符号库中的名字与C语言的不同。例如，假设某个函数的原型为：void foo( int x, int y );该函数被C编译器编译后在符号库中的名字为_foo，而C++编译器则会产生像_foo_int_int之类的名字（不同的编译器可能生成的名字不同，但是都采用了相同的机制，生成的新名字称为“mangled name”）。_foo_int_int这样的名字包含了函数名、函数参数数量及类型信息，C++就是靠这种机制来实现函数重载的。例如，在C++中，函数void foo( int x, int y )与void foo( int x, float y )编译生成的符号是不相同的，后者为_foo_int_float。同样地，C++中的变量除支持局部变量外，还支持类成员变量和全局变量。用户所编写程序的类成员变量可能与全局变量同名，我们以"."来区分。而本质上，编译器在进行编译时，与函数的处理相似，也为类中的变量取了一个独一无二的名字，这个名字与用户程序中同名的全局变量名字不同。

未加extern "C"声明时的连接方式

假设在C++中，模块A的头文件如下：

// 模块A头文件　moduleA.h

#ifndef MODULE_A_H

#define MODULE_A_H

int foo( int x, int y );

#endif

在模块B中引用该函数：

// 模块B实现文件　moduleB.cpp

#include "moduleA.h"

foo(2,3);

实际上，在连接阶段，连接器会从模块A生成的目标文件moduleA.obj中寻找_foo_int_int这样的符号！

加extern "C"声明后的编译和连接方式

加extern "C"声明后，模块A的头文件变为：

// 模块A头文件　moduleA.h

#ifndef MODULE_A_H

#define MODULE_A_H

extern "C" int foo( int x, int y );

#endif

在模块B的实现文件中仍然调用foo( 2,3 )，其结果是：

（1）模块A编译生成foo的目标代码时，没有对其名字进行特殊处理，采用了C语言的方式；

（2）连接器在为模块B的目标代码寻找foo(2,3)调用时，寻找的是未经修改的符号名_foo。

如果在模块A中函数声明了foo为extern "C"类型，而模块B中包含的是extern int foo( int x, int y ) ，则模块B找不到模块A中的函数；反之亦然。所以，可以用一句话概括extern “C”这个声明的真实目的： 实现C++与C及其它语言的混合编程。

extern "C"的惯用法

明白了C++中extern "C"的设立动机，我们下面来具体分析extern "C"通常的使用技巧：

（1）在C++中引用C语言中的函数和变量

在C++中引用C语言中的函数和变量，在包含C语言头文件（假设为cExample.h）时，需进行下列处理：

extern "C"

{

#include "cExample.h"

}

而在C语言的头文件中，对其外部函数只能指定为extern类型，C语言中不支持extern "C"声明，在.c文件中包含了extern "C"时会出现编译语法错误。C++引用C函数例子工程中包含的三个文件的源代码如下：

/*c语言头文件：cExample.h */

#ifndef C_EXAMPLE_H

#define C_EXAMPLE_H

extern int add(int x,int y);

#endif

/*c语言实现文件：cExample.c */

#include "cExample.h"

int add( int x, int y )

{

return x + y;

}

//c++实现文件，调用add：cppFile.cpp

extern "C"

{

#include "cExample.h"

}

int main(int argc, char* argv[])

{

add(2,3);

return 0;

}

如果C++调用一个C语言编写的.DLL时，当包括.DLL的头文件或声明接口函数时，应加extern "C" {　}。

（2）c语言中引用C++中的函数和变量

在C++引用C语言中的函数和变量时，C++的头文件需添加extern "C"，但是在C语言中不能直接引用声明了extern "C"的该头文件，应该仅将C文件中将C++中定义的extern "C"函数声明为extern类型。C引用C++函数例子工程中包含的三个文件的源代码如下：

//C++头文件 cppExample.h

#ifndef CPP_EXAMPLE_H

#define CPP_EXAMPLE_H

extern "C" int add( int x, int y );

#endif

//C++实现文件 cppExample.cpp

#include "cppExample.h"

int add( int x, int y )

{

return x + y;

}

/* C实现文件 cFile.c

/* 这样会编译出错：#include "cppExample.h" */

extern int add( int x, int y );

int main( int argc, char* argv[] )

{

add( 2, 3 );

return 0;

}

第一个程序的解读

#ifdef __cplusplus

extern "C" { 

#endif 

... 

#ifdef __cplusplus

} 

#endif 

1、c++中默认定义了__cplusplus，C语言中没有该定义，即：识别是c代码还是c++代码，这符合上面第一种使用情况的结论。如下段代码：

2、C语言和C++编译出来的函数不用，调用extern "C"会让c++编译器按照c的编译格式来编译，多用于c++库的头文件，这也符合上面的结论。

————————————————

版权声明：本文为CSDN博主「小伙子wp」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/w2865673691/article/details/13018563