名字修飾約定: extern "C"、extern "C++" 和__stdcall、__cdecl相關的約定、__imp_前綴

關於extern_C
通常，在C語言的頭文件中經常可以看到類似下面這種形式的代碼

#ifdef  __cplusplus  
extern "C" {  
#endif  


/**** some declaration or so *****/  


#ifdef  __cplusplus  
}  
#endif  /* end of __cplusplus */  

那麼，這種寫法什麼用呢？實際上，這是爲了讓CPP能夠與C接口而採用的一種語法形式。之所以採用這種方式，是因爲兩種語言之間的一些差異所導致的。由於CPP支持多態性，也就是具有相同函數名的函數可以完成不同的功能，CPP通常是通過參數區分具體調用的是哪一個函數。在編譯的時候，CPP編譯器會將參數類型和函數名連接在一起，於是在程序編譯成爲目標文件以後，CPP編譯器可以直接根據目標文件中的符號名將多個目標文件連接成一個目標文件或者可執行文件。但是在C語言中，由於完全沒有多態性的概念，C編譯器在編譯時除了會在函數名前面添加一個下劃線之外，什麼也不會做（至少很多編譯器都是這樣乾的）。由於這種的原因，當採用CPP與C混合編程的時候，就可能會出問題。假設在某一個頭文件中定義了這樣一個函數：

int foo(int a, int b);  

而這個函數的實現位於一個.c文件中，同時，在.cpp文件中調用了這個函數。那麼，當CPP編譯器編譯這個函數的時候，就有可能會把這個函數名改成_fooii，這裏的ii表示函數的第一參數和第二參數都是整型。而C編譯器卻有可能將這個函數名編譯成_foo。也就是說，在CPP編譯器得到的目標文件中，foo()函數是由_fooii符號來引用的，而在C編譯器生成的目標文件中，foo()函數是由_foo指代的。但連接器工作的時候，它可不管上層採用的是什麼語言，它只認目標文件中的符號。於是，連接器將會發現在.cpp中調用了foo()函數，但是在其它的目標文件中卻找不到_fooii這個符號，於是提示連接過程出錯。extern “C” {}這種語法形式就是用來解決這個問題的。本文將以示例對這個問題進行說明。

首先假設有下面這樣三個文件：

在這個頭文件中只定義了一個函數，ThisIsTest()。這個函數被定義爲一個外部函數，可以被包括到其它程序文件中。假設ThisIsTest()函數的實現位於test_extern_c.c文件中：

/* test_extern_c.c */  

#include "test_extern_c.h"  

int ThisIsTest(int a, int b)  
{  
    return (a + b);  
}  

可以看到，ThisIsTest()函數的實現非常簡單，就是將兩個參數的相加結果返回而已。現在，假設要從CPP中調用ThisIsTest()函數：

/* main.cpp */  
#include "test_extern_c.h"  
#include <stdio.h>  
#include <stdlib.h>  

class FOO {  
public:  

int bar(int a, int b)  
{  
    printf("result=%i\n", ThisIsTest(a, b));  
}  
};  

int main(int argc, char **argv)  
{  
    int a = atoi(argv[1]);  
    int b = atoi(argv[2]);   

    FOO *foo = new FOO();  

    foo->bar(a, b);  

    return(0);  
}  

在這個CPP源文件中，定義了一個簡單的類FOO，在其成員函數bar()中調用了ThisIsTest()函數。下面看一下如果採用gcc編譯test_extern_c.c，而採用g++編譯main.cpp並與test_extern_c.o連接會發生什麼情況

[cyc@cyc src]$ gcc -c test_extern_c.c  

[cyc@cyc src]$ g++ main.cpp test_extern_c.o  

[cyc@cyc src]$ ./a.out 4 5                  

result=9

可以看到，程序沒有任何異常，完全按照預期的方式工作。那麼，如果將test_extern_c.h中的extern “C” {}所在的那幾行註釋掉會怎樣呢？註釋後的test_extern_c.h文件內容如下：

 /* test_extern_c.h */  
#ifndef __TEST_EXTERN_C_H__  
#define __TEST_EXTERN_C_H__  

//#ifdef   __cplusplus  
//extern "C" {  
//#endif  

/*  
 * this is a test function, which calculate  
 * the multiply of a and b.  
 */  

extern int ThisIsTest(int a, int b);  


//#ifdef   __cplusplus  
//  }  
//#endif   /* end of __cplusplus */  

#endif  

除此之外，其它文件不做任何的改變，仍然採用同樣的方式編譯test_extern_c.c和main.cpp文件：

[cyc@cyc src]$ gcc -c test_extern_c.c  

[cyc@cyc src]$ g++ main.cpp test_extern_c.o  

/tmp/cca4EtJJ.o(.gnu.linkonce.t._ZN3FOO3barEii+0x10): In function `FOO::bar(int, int)':  

: undefined reference to `ThisIsTest(int, int)'  

collect2: ld returned 1 exit status  

在編譯main.cpp的時候就會出錯，連接器ld提示找不到對函數ThisIsTest()的引用。

爲了更清楚地說明問題的原因，我們採用下面的方式先把目標文件編譯出來，然後看目標文件中到底都有些什麼符號：

[cyc@cyc src]$ gcc -c test_extern_c.c      

[cyc@cyc src]$ objdump -t test_extern_c.o  

test_extern_c.o:     file format elf32-i386  

SYMBOL TABLE:  

00000000 l    df *ABS*  00000000 test_extern_c.c  

00000000 l    d  .text  00000000  

00000000 l    d  .data  00000000  

00000000 l    d  .bss   00000000  

00000000 l    d  .comment       00000000  

00000000 g     F .text  0000000b ThisIsTest  
[cyc@cyc src]$ g++ -c main.cpp            
[cyc@cyc src]$ objdump -t main.o          
main.o:     file format elf32-i386  
SYMBOL TABLE:  

00000000 l    df *ABS*  00000000 main.cpp  

00000000 l    d  .text  00000000  

00000000 l    d  .data  00000000  

00000000 l    d  .bss   00000000  

00000000 l    d  .rodata        00000000  

00000000 l    d  .gnu.linkonce.t._ZN3FOO3barEii 00000000  

00000000 l    d  .eh_frame      00000000  

00000000 l    d  .comment       00000000  

00000000 g     F .text  00000081 main  

00000000         *UND*  00000000 atoi  

00000000         *UND*  00000000 _Znwj  

00000000         *UND*  00000000 _ZdlPv  

00000000  w    F .gnu.linkonce.t._ZN3FOO3barEii 00000027 _ZN3FOO3barEii  

00000000         *UND*  00000000 _Z10ThisIsTestii  

00000000         *UND*  00000000 printf  

00000000         *UND*  00000000 __gxx_personality_v0  

可以看到，採用gcc編譯了test_extern_c.c之後，在其目標文件test_extern_c.o中的有一個ThisIsTest符號，這個符號就是源文件中定義的ThisIsTest()函數了。而在採用g++編譯了main.cpp之後，在其目標文件main.o中有一個_Z10ThisIsTestii符號，這個就是經過g++編譯器“粉碎”過後的函數名。其最後的兩個字符i就表示第一參數和第二參數都是整型。而爲什麼要加一個前綴_Z10我並不清楚，但這裏並不影響我們的討論，因此不去管它。顯然，這就是原因的所在，其原理在本文開頭已作了說明。

[cyc@cyc src]$ gcc -c test_extern_c.c  

[cyc@cyc src]$ objdump -t test_extern_c.o  

test_extern_c.o:     file format elf32-i386  

SYMBOL TABLE:  

00000000 l    df *ABS*  00000000 test_extern_c.c  

00000000 l    d  .text  00000000  

00000000 l    d  .data  00000000  

00000000 l    d  .bss   00000000  

00000000 l    d  .comment       00000000  

00000000 g     F .text  0000000b ThisIsTest  

那麼，爲什麼採用了extern “C” {}形式就不會有這個問題呢，我們就來看一下當test_extern_c.h採用extern “C” {}的形式時編譯出來的目標文件中又有哪些符號：

[cyc@cyc src]$ g++ -c main.cpp  

[cyc@cyc src]$ objdump -t main.o  

main.o:     file format elf32-i386  

SYMBOL TABLE:  

00000000 l    df *ABS*  00000000 main.cpp  

00000000 l    d  .text  00000000  

00000000 l    d  .data  00000000  

00000000 l    d  .bss   00000000  

00000000 l    d  .rodata        00000000  

00000000 l    d  .gnu.linkonce.t._ZN3FOO3barEii 00000000  

00000000 l    d  .eh_frame      00000000  

00000000 l    d  .comment       00000000  

00000000 g     F .text  00000081 main  

00000000         *UND*  00000000 atoi  

00000000         *UND*  00000000 _Znwj  

00000000         *UND*  00000000 _ZdlPv  

00000000  w    F .gnu.linkonce.t._ZN3FOO3barEii 00000027 _ZN3FOO3barEii  

00000000         *UND*  00000000 ThisIsTest  

00000000         *UND*  00000000 printf  

00000000         *UND*  00000000 __gxx_personality_v0  

注意到這裏和前面有什麼不同沒有，可以看到，在兩個目標文件中，都有一個符號ThisIsTest，這個符號引用的就是ThisIsTest()函數了。顯然，此時在兩個目標文件中都存在同樣的ThisIsTest符號，因此認爲它們引用的實際上同一個函數，於是就將兩個目標文件連接在一起，凡是出現程序代碼段中有ThisIsTest符號的地方都用ThisIsTest()函數的實際地址代替。另外，還可以看到，僅僅被extern “C” {}包圍起來的函數採用這樣的目標符號形式，對於main.cpp中的FOO類的成員函數，在兩種編譯方式後的符號名都是經過“粉碎”了的。

因此，綜合上面的分析，我們可以得出如下結論：採用extern “C” {} 這種形式的聲明，可以使得CPP與C之間的接口具有互通性，不會由於語言內部的機制導致連接目標文件的時候出現錯誤。需要說明的是，上面只是根據我的試驗結果而得出的結論。由於對於CPP用得不是很多，瞭解得也很少，因此對其內部處理機制並不是很清楚，如果需要深入瞭解這個問題的細節請參考相關資料。

備註：
1. 對於要在cpp中使用的在c文件中寫好的函數func()，只需要在c文件的頭文件中添加extern “C”聲明就可以了。比如：extern “C” func() { …}

當然，可以使用

#ifdef __cplusplus

extern "C" {

#endif

和


#ifdef __cplusplus

}

#endif

將整個c文件的函數全都括起來

C++保留了一部分過程式語言的特點，因而它可以定義不屬於任何類的全局變量和函數。但是，C++畢竟是一種面向對象的程序設計語言，爲了支持函數的重載，C++對全局函數的處理方式與C有明顯的不同。
extern “C”的主要作用就是爲了能夠正確實現C++代碼調用其他C語言代碼。加上extern “C”後，會指示編譯器這部分代碼按C語言的進行編譯，而不是C++的。由於C++支持函數重載，因此編譯器編譯函數的過程中會將函數的參數類型也加到編譯後的代碼中，而不僅僅是函數名；而C語言並不支持函數重載，因此編譯C語言代碼的函數時不會帶上函數的參數類型，一般之包括函數名。
比如說你用C 開發了一個DLL 庫，爲了能夠讓C ++語言也能夠調用你的DLL輸出(Export)的函數，你需要用extern “C”來強制編譯器不要修改你的函數名。

揭祕extern “C”

從標準頭文件說起

#ifndef __INCvxWorksh  /*防止該頭文件被重複引用*/
#define __INCvxWorksh

#ifdef __cplusplus    //__cplusplus是cpp中自定義的一個宏
extern "C" {          //告訴編譯器，這部分代碼按C語言的格式進行編譯，而不是C++的
#endif

    /**** some declaration or so *****/  

#ifdef __cplusplus
}
#endif

#endif /* __INCvxWorksh */

extern “C”的含義

extern “C” 包含雙重含義，從字面上即可得到：首先，被它修飾的目標是“extern”的；其次，被它修飾的目標是“C”的。
被extern “C”限定的函數或變量是extern類型的；
1、extern關鍵字
extern是C/C++語言中表明函數和全局變量作用範圍（可見性）的關鍵字，該關鍵字告訴編譯器，其聲明的函數和變量可以在本模塊或其它模塊中使用。
通常，在模塊的頭文件中對本模塊提供給其它模塊引用的函數和全局變量以關鍵字extern聲明。例如，如果模塊B欲引用該模塊A中定義的全局變量和函數時只需包含模塊A的頭文件即可。這樣，模塊B中調用模塊A中的函數時，在編譯階段，模塊B雖然找不到該函數，但是並不會報錯；它會在鏈接階段中從模塊A編譯生成的目標代碼中找到此函數。
與extern對應的關鍵字是static，被它修飾的全局變量和函數只能在本模塊中使用。因此，一個函數或變量只可能被本模塊使用時，其不可能被extern “C”修飾。

2、被extern “C”修飾的變量和函數是按照C語言方式編譯和鏈接的
首先看看C++中對類似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++中的變量除支持局部變量外，還支持類成員變量和全局變量。用戶所編寫程序的類成員變量可能與全局變量同名，我們以”.”來區分。而本質上，編譯器在進行編譯時，與函數的處理相似，也爲類中的變量取了一個獨一無二的名字，這個名字與用戶程序中同名的全局變量名字不同。

3、舉例說明
（1）未加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這樣的符號！

（2）加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及其它語言的混合編程。

應用場合

C++代碼調用C語言代碼、在C++的頭文件中使用
在C++中引用C語言中的函數和變量，在包含C語言頭文件（假設爲cExample.h）時，需進行下列處理：

extern "C"
{
#include "cExample.h"
}

而在C語言的頭文件中，對其外部函數只能指定爲extern類型，C語言中不支持extern “C”聲明，在.c文件中包含了extern “C”時會出現編譯語法錯誤

/* c語言頭文件：cExample.h */
#ifndef C_EXAMPLE_H
#define C_EXAMPLE_H
extern int add(int x,int y);     //注:寫成extern "C" int add(int , int ); 也可以
#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"        //注：此處不妥，如果這樣編譯通不過，換成 extern "C" int add(int , int ); 可以通過
}

int main(int argc, char* argv[])
{
　add(2,3);
　return 0;
}

如果C++調用一個C語言編寫的.DLL時，當包括.DLL的頭文件或聲明接口函數時，應加extern “C”{}。

在C中引用C++語言中的函數和變量時，C++的頭文件需添加extern “C”，但是在C語言中不能直接引用聲明瞭extern “C”的該頭文件，應該僅將C文件中將C++中定義的extern “C”函數聲明爲extern類型

//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 "cExample.h" */
extern int add( int x, int y );
int main( int argc, char* argv[] )
{
　add( 2, 3 );
　return 0;
}

 

 

===================================================================

所謂名字修飾約定，就是指變量名、函數名等經過編譯後重新輸出名稱的規則。
比如源代碼中函數名稱爲int Func(int a,int b)，經過編譯後名稱可能爲?Func@@YAHHH@Z、?Func@@YGHHH@Z、_Func@8，也有可能與源代碼中名稱相同爲Func。
影響編譯後輸出的名稱通常與名字修飾約定（extern "C"、extern "C++"等）和函數調用約定（__stdcall、__cdecl等）等相關。

首先，用C方式導出兩個函數：

Dll1.c

_declspec(dllexport) int __cdecl Func_cdecl(int a,int b){    return 1;} 

_declspec(dllexport) int __stdcall Func_stdcall(int a,int b){    return 1;} 

導出的兩個函數名爲：

再以C++方式導出：
Dll1.cpp

_declspec(dllexport) int __cdecl Func_cdecl(int a,int b){    return 1;} 

_declspec(dllexport) int __stdcall Func_stdcall(int a,int b){    return 1;} 

導出的兩個函數名爲：

 

 

然後，我們再以C++方式導出如下代碼中的函數：

extern "C" _declspec(dllexport) int __stdcall Func_C_stdcall(int a,int b){    return 1;} 

extern "C++" _declspec(dllexport) int __stdcall Func_CPP_stdcall(int a,int b){   return 1;} 

extern "C" _declspec(dllexport) int __cdecl Func_C_cdecl(int a,int b){    return 1;} 

extern "C++" _declspec(dllexport) int __cdecl Func_CPP_cdecl(int a,int b){    return 1;} 

導出結果如下：

 

有了以上實驗結果，我們再結合以下名字輸出規則進行理解：

C方式編譯（extern "C"）：

__stdcall調用約定：輸出名稱在原名稱前加一下劃線，後面再加上一個“@”和其參數的總字節數（_原名稱@參數總字節數），如名稱int
 Func_C_stdcall(int a,int b)輸出爲_Func_C_stdcall@8；

__cdecl調用約定：與原名稱相同，如名稱int Func_C_cdecl(int a,int b)輸出還是爲Func_C_cdecl；

C++方式編譯（extern "C++"）：

__stdcall調用約定：
輸出名稱以“?”開始，後跟原名稱；原名稱後再跟“@@YG”，後面再跟返回值代號和參數表代號，代號表示如下：

• X--void ，
• D--char，
• E--unsigned char，
• F--short，
• H--int，
• I--unsigned int，
• J--long，
• K--unsigned long，
• M--float，
• N--double，
• _N--bool，
• ...

PA--表示指針，後面的代號表明指針類型，如果相同類型的指針連續出現，以“0”代替，一個“0”代表一次重複；參數表後以“@Z”標識整個名字的結束，如果該函數無參數，則以“Z”標識結束。如名稱int Func_CPP_stdcall(int a,int b)編譯後的輸出名稱爲?Func_CPP_stdcall@@YGHHH@Z。__cdecl調用約定：與_stdcall調用約定基本一致，只是參數表的開始標識由上面的“@@YG”變爲“@@YA”。如名稱int
 Func_CPP_cdecl(int a,int b)編譯後輸出名稱爲?Func_CPP_cdecl@@YAHHH@Z。

有個這個規則，再回頭去看我們的實驗結果，就很好理解了。
當然，編譯C文件和編譯CPP文件，不需加extern"C"和extern "C++"，

因爲編譯C文件當然默認的是extern "C"，而編譯CPP文件則默認的是extern"C++"。

現在我們也能理解爲什麼導出DLL時通常需要加上extern"C"。試想，如果一個C++導出的dll，沒有加extern "C"，則導出的名稱爲extern "C++"約定下的名稱。如果這個dll需要提供給用C編寫的程序使用，那麼這個程序是無法調用這個dll的，因爲C寫的程序遵循的是extern "C"約定，鏈接時鏈接器將按照extern "C"約定的名稱去尋找外部名稱，這當然找不到，因爲dll中的輸出名稱爲extern "C++"約定下的名稱。

================================================================

就以爲是約定俗成，其實也算是約定俗成，這樣做的目的是爲了防止符號名衝突，因爲在一個程序中往往是包含彙編和C文件的，彙編用於啓動部分，C文件用於應用程序，最終通過編譯器實現編譯，對於編譯器來說，彙編和C是一視同仁的，那麼就會有個問題，如果在彙編和C文件中使用了同一個名字，這是很可能出現的，畢竟彙編相當於機器碼也算是稍微高級的語言，在定義子程序或函數時，也是可以用英文拼寫的，而C文件中，更會習慣用英文拼寫。

    所以爲了防止類似的符號名衝突，UNIX下的C語言就規定，C語言的源代碼文件中的所有全局變量和函數經過編譯後，相應的符號名前面會自動的加上下劃線“_”。這樣做的好處，就是方便是程序開發人員，不用太小心翼翼的起名，避免了與彙編文件中的符號名的衝突。

==================================================================

有關DLL的問題現在資料很多，但是很多人寫DLL時經常出現調用程序無法找到相關的導出函數的問題，這裏主要的原因是DLL在聲明時出的問題。
在這裏主要有兩個問題，一個是調用約定的問題，一個是函數名修飾的問題，而這兩個問題又是相互影響的。
一：聲明爲：extern "C" int __declspec(dllexport)add(int x, int y);
這種聲明是強制用C語言方式進行修飾，且用C的默認約定，即__cdecl方式。這種方式編譯產生的DLL中有一個導出函數：add，不加任何修飾。
二：聲明爲：extern "C" int __declspec(dllexport) __stdcall add(int x, int y);
這種聲明是強制用C語言方式進行修飾，且用stdcall約定，這種方式編譯產生的DLL中有一個導出函數：_add@8，即前面有“_”，後面加了參數長。
三：聲明爲：int __declspec(dllexport) __stdcall add(int x, int y);
這種聲明不強制用C語言方式進行修飾，但是用stdcall約定，這種方式編譯產生的DLL中有一個導出函數：?add@@YGHHH@Z。這個名字很怪，後面的不好理解。
四：聲明爲：int __declspec(dllexport) __cdecl add(int x, int y);
這種聲明是不強制用C語言修飾，且用cdecl約定，這種方式編譯產生的DLL中有一個導出函數：?add@@YAHHH@Z，注意看，和第三種方有一點不同。

實驗一：顯式調用方式調用DLL中的add函數。

#include <stdio.h>
#include <windows.h>
typedef  int(_stdcall *lpAddFun)(int, int); //宏定義函數指針類型
int main(int argc, char *argv[])
{
HINSTANCE hDll; //DLL句柄 
lpAddFun addFun; //函數指針
hDll = LoadLibrary("1.dll");
if (hDll != NULL)
{
addFun = (lpAddFun)GetProcAddress(hDll, "add");
if (addFun != NULL)
{
int result = addFun(2, 3);
printf("%d", result);
}
else
printf("No Function");
}
else
printf("NO DLL");
FreeLibrary(hDll);
return 0;
}
方式一：調用成功。另外三種方式全部出錯
實驗二：隱式調用DLL中的add函數
#include <stdio.h>
#include <windows.h>
#pragma comment(lib,"1.lib") 
extern "C" int __declspec(dllimport) add(int x, int y);//聲明方式隨着DLL中的聲明方式改變
int main(int argc, char *argv[])
{
int result = add(2, 3);
printf("%d", result);
return 0;
}

方式一：調用成功。另外發現一個奇怪現象：在調用程序中
聲明函數時extern "C" int __declspec(dllimport) add(int x, int y);
寫作：extern "C" int __declspec(dllecprot) add(int x, int y);同樣成功，將__declspec(…)去掉也同樣成功。換句話說，在調用DLL的程序中，導入是沒有必要加的。
方式二：調用成功。同樣出現上面導入標識可以不加的現象。
方式三：調用成功，同樣也出現上面導入標識可以不加的現象。
方式四：調用成功，同樣也出現上面導入標識可以不加的現象。
總結：對於DLL導出函數聲明的四種寫法，在動態調用時，
聲明成這樣：extern "C" int __declspec(dllimport) add(int x, int y);是最好的，其它聲明方式調用都沒有成功。但是衆所周知，windows默認的調用約定是stdcall方式，如果想別的語言能用DLL的話，最好是將調用約定寫成stdcall方式，但是這種方式又不能動態調用。
在隱式調用時，四種聲明方式都是可以的，只要調用者的聲明方式和DLL聲明時的方式一致即可。另外，在調用程序中對於導入的聲明是可以去掉的，大量書籍中關於導入、導出的問題都是利用宏來處理的，如：在頭文件中寫作：
#ifdef DLL_FILE
extern "C" int __declspec(dllexport) add(int x, int y);
#else
extern "C" int __declspec(dlleximport) add(int x, int y);
這樣這個頭文件既可以用在DLL工程中，又可以用在調用程序中，但是經過實驗發現，這個根本就沒有必要，在調用者程序中不管是寫作__declspce(dllexport)還是寫作__declspec(dllimport)或者不寫都能成功調用。
關於DEF文件
在DLL工程中引用DEF文件，內容如下：
LIBRARY 1
EXPORTS
add @ 1
通過depends查看導出函數全是add，但是隱式方式調用時，還是要求調用者的聲明方式和DLL中聲明方式相同。
對於動態調用實驗結果：
方式一：成功。方式二：不成功，但是將函數指針改爲typedef int(_stdcall *lpAddFun)(int, int);成功，即調用者要聲明約定方式與DLL中聲明的調用約定方式相同，否則報錯。
方式三：同方式二，同樣要將函數指針改爲typedef int(_stdcall *lpAddFun)(int, int)；才成功完成調用。
方式四：成功。
總結：通過DEF文件來導出函數，調用者同樣也要聲明相同的調用約定，即_stdcall或是_cdecl必須要相同，其中_cdecl是C語言默認方式。

=================================================================

__imp,說明那不是真正的靜態庫，而是某個動態庫的導入庫
導入函數和函數自己不同名，所以加__imp
比如__imp_printf忘了有沒有後綴了，就是 printf函數

所謂名字修飾約定，就是指變量名、函數名等經過編譯後重新輸出名稱的規則。
比如源代碼中函數名稱爲int Func(int a,int b)，經過編譯後名稱可能爲?Func@@YAHHH@Z、?Func@@YGHHH@Z、_Func@8，也有可能與源代碼中名稱相同爲Func。
影響編譯後輸出的名稱通常與名字修飾約定（extern "C"、extern "C++"等）和函數調用約定（__stdcall、__cdecl等）等相關。
口說千遍，不如實際演練一遍。那麼，就讓我們寫代碼來測試下。
注意，本文只討論extern
 extern "C"、extern "C++" 和__stdcall、__cdecl相關的約定，其他約定不在本文討論範圍內。

另外，編譯的環境爲WIN10  + VC2013

extern "C"+__cdecl

gpleadrailcontrol.h

#ifndef _GP_LEAD_RAIL_CONTROL_H_
#define _GP_LEAD_RAIL_CONTROL_H_

#ifdef GPLEADRAILCONTROL_EXPORTS
# define CTRL_API __declspec(dllexport)
#else
# define CTRL_API __declspec(dllimport)
#endif

#ifdef  __cplusplus
# define MODBUS_BEGIN_DECLS  extern "C" {
# define MODBUS_END_DECLS    }
#else
# define MODBUS_BEGIN_DECLS
# define MODBUS_END_DECLS
#endif

MODBUS_BEGIN_DECLS

#define GP_LR_RET_SUCCESS 0		// 返回成功	
#define GP_LR_RET_ERROR   -1    // 返回錯誤
#define GP_LR_SET_SUCCESS 1		// 導軌控制設置成功
#define GP_LR_SET_FAILED  2     // 導軌控制設置失敗


typedef struct _GP_LR_MOVE_DATA_
{
	char chDirection;			// 方向
	int  nSpeed;				// 速度等級
	int  nAcceleration;			// 加速度等級
	int  nPulseCount;			// 脈衝數
}GP_LR_MOVE_DATA;

int		CTRL_API GP_LR_Init(char* pComNameOrIpAddr, int nBaudRateOrPort);
void	CTRL_API GP_LR_Deinit();
int	    CTRL_API GP_LR_Open(int nDevIndex);
int     CTRL_API GP_LR_Close(int nDevIndex);
int     CTRL_API GP_LR_Home(int nDevIndex);
int	    CTRL_API GP_LR_Move(int nDevIndex, GP_LR_MOVE_DATA* pMoveData);
int		CTRL_API GP_LR_Stop(int nDevIndex);
int		CTRL_API GP_LR_SetSpeed(int nDevIndex,int nSpeed);
int		CTRL_API GP_LR_SetAcceleration(int nDevIndex, int nAcceleration);
int     CTRL_API GP_LR_GetInfo(int nDevIndex, GP_LR_MOVE_DATA* pstLrPositionInfo);

MODBUS_END_DECLS
#endif // _GP_LEAD_RAIL_CONTROL_H_

gpleadrailcontrol.cpp

// gpleadrailcontrol.cpp : Defines the exported functions for the DLL application.
#include "gpleadrailcontrol.h"
#include "LeadRailCtrl.h"
#include "singleton_instance.hpp"


extern "C"
{

	int CTRL_API GP_LR_Init(char* pComNameOrIpAddr, int nBaudRateOrPort)
	{
		int nRet = base::singleton_instance<LeadRailCtrl>::instance()->Init(pComNameOrIpAddr, nBaudRateOrPort);
		return nRet;
	}

	void CTRL_API GP_LR_Deinit()
	{
		base::singleton_instance<LeadRailCtrl>::instance()->DeInit();
	}

	int CTRL_API GP_LR_Open(int nDevIndex)
	{
		int nRet = base::singleton_instance<LeadRailCtrl>::instance()->OpenLR(nDevIndex);
		return nRet;
	}
	int CTRL_API GP_LR_Close(int nDevIndex)
	{
		int nRet = base::singleton_instance<LeadRailCtrl>::instance()->CloseLR(nDevIndex);
		return nRet;
	}
	int CTRL_API GP_LR_Home(int nDevIndex)
	{
		GP_LR_MOVE_DATA stLrMoveData = { 0 };
		int nRet = base::singleton_instance<LeadRailCtrl>::instance()->HomeLR(nDevIndex);
		return nRet;
	}
	int CTRL_API GP_LR_Move(int nDevIndex, GP_LR_MOVE_DATA* pMoveData)
	{
		int nRet = base::singleton_instance<LeadRailCtrl>::instance()->MoveLR(nDevIndex, pMoveData);
		return nRet;
	}

	int CTRL_API GP_LR_Stop(int nDevIndex)
	{
		int nRet = base::singleton_instance<LeadRailCtrl>::instance()->StopLR(nDevIndex);
		return nRet;
	}

	int	CTRL_API GP_LR_SetSpeed(int nDevIndex, int nSpeed)
	{
		int nRet = base::singleton_instance<LeadRailCtrl>::instance()->SetSpeed(nDevIndex, nSpeed);
		return nRet;
	}

	int	CTRL_API GP_LR_SetAcceleration(int nDevIndex, int nAcceleration)
	{
		int nRet = base::singleton_instance<LeadRailCtrl>::instance()->SetAcceleration(nDevIndex, nAcceleration);
		return nRet;
	}

	int CTRL_API GP_LR_GetInfo(int nDevIndex, GP_LR_MOVE_DATA* pstLrPositionInfo)
	{
		int nRet = base::singleton_instance<LeadRailCtrl>::instance()->GetCurrentInfo(nDevIndex, pstLrPositionInfo);
		return nRet;
	}


}

 

結果gpleadrailcontrol.dll的導入庫gpleadrailcontrol.lib

 

二、extern "C"+__stdcall

如果屏蔽頭文件中的//MODBUS_BEGIN_DECLS //MODBUS_END_DECLS編譯會報錯

 

 

__cdecl (/Gd):?xxxx@@YAHPADH@Z   同 代碼中有extern"C++" +__cdecl (/Gd)

__stdcall (/Gz):?xxxx@@YGHPADH@Z 同 代碼中有extern"C++" +__cdecl (/Gd)

 

__fastcall (/Gr):?xxxx@@YIHPADH@Z 同 代碼中有extern"C++" +__cdecl (/Gd)

__vectorcall (/Gv):?xxxx@@YQHPADH@Z 同 代碼中有extern"C++" +__cdecl (/Gd)

 

代碼有extern"C" + __cdecl (/Gd):_xxxx

代碼有extern"C" __stdcall (/Gz):_xxxx@8

 

代碼有extern"C" __fastcall (/Gr):@xxxx@8

代碼有extern"C" __vectorcall (/Gv):xxxx@@8