http://blog.csdn.net/slj_win/article/details/32312457
2014
extern "C" __stdcall對(duì)函數(shù)的使用聲明如下：
1 extern "C"：
在當(dāng)調(diào)用別人寫(xiě)的庫(kù)時(shí)，注意庫(kù)是使用何種編譯器，若是C的，則你在用VC中的C++編譯器調(diào)用時(shí)就得加
#if defined(__cplusplus)
extern "C" {
#endif
..........聲明被調(diào)用的函數(shù)名
#if defined(__cplusplus)
};
#endif
這樣就可以讓C++使用因編譯器不同導(dǎo)致的名稱不同的函數(shù)?。?！
2 __stdcall: (部分轉(zhuǎn)載)
__stdcall是最常用的方式（API）
__cdecl是C和C＋＋程序的缺省調(diào)用方式。
__stdcall __cdecl使用的意義在于：當(dāng)我們使用動(dòng)態(tài)連接庫(kù)的時(shí)候，需要聲明類型，在調(diào)用的時(shí)候類型要一致，否則會(huì)應(yīng)壓棧等方式不同而可能錯(cuò)誤如下：
DLL中：
int _declspec(dllexport) __stdcall IDTS_BV(BVinfo *Bvinforma)
調(diào)用程序中：
typedef int (*pIDTS_IDTS_SetBV)(BVinfo *Adinfo_para);//__stdcall 未添加
pIDTS_IDTS_SetBV IDTS_SetBV；
DllHandle = LoadLibrary(m_DriverName);
IDTS_SetBV = (pIDTS_IDTS_SetBV) GetProcAddress(DllHandle, "IDTS_BV"))；
調(diào)用 可能 出錯(cuò)！這兩種壓棧方式一樣，而且只有一個(gè)變量 好像不出錯(cuò)?。。。。。。。。。。。。。。。。。。?！
至于這種函數(shù)被調(diào)用，則和普通的cdecl及stdcall調(diào)用函數(shù)一致。函數(shù)調(diào)用約定導(dǎo)致的常見(jiàn)問(wèn)題如果定義的約定和使用的約定不一致，則將導(dǎo)致堆棧被破壞，導(dǎo)致嚴(yán)重問(wèn)題，下面是兩種常見(jiàn)的問(wèn)題：
函數(shù)原型聲明和函數(shù)體定義不一致
DLL導(dǎo)入函數(shù)時(shí)聲明了不同的函數(shù)約定
以后者為例，假設(shè)我們?cè)赿ll種聲明了一種函數(shù)為：
__declspec(dllexport) int func(int a,int b);//注意，這里沒(méi)有stdcall，使用的是
cdecl
使用時(shí)代碼為：
typedef int (*WINAPI DLLFUNC)func(int a,int b);
hLib = LoadLibrary(...);
DLLFUNC func = (DLLFUNC)GetProcAddress(...)//這里修改了調(diào)用約定
result = func(1,2);//導(dǎo)致錯(cuò)誤
由于調(diào)用者沒(méi)有理解WINAPI的含義錯(cuò)誤的增加了這個(gè)修飾，上述代碼必然導(dǎo)致堆棧被破壞，MFC在編譯時(shí)插入的checkesp函數(shù)將告訴你，堆棧被破壞了。
每一個(gè)調(diào)用它的函數(shù)都包含清空堆棧的代碼，所以產(chǎn)生的可執(zhí)行文件大小會(huì)比調(diào)用__stdcall函數(shù)的大。函數(shù)采用從右到左的壓棧方式。VC將函數(shù)編譯后會(huì)在函數(shù)名前面加上下劃線前綴。
__stdcall是Pascal程序的缺省調(diào)用方式，通常用于Win32 Api中，函數(shù)采用從右到左的壓棧方式，自己在退出時(shí)清空堆棧。VC將函數(shù)編譯后會(huì)在函數(shù)名前面加上下劃線前綴，在函數(shù)名后加上"@"和參數(shù)的字節(jié)數(shù)。
__fastcall方式的函數(shù)采用寄存器傳遞參數(shù)，VC將函數(shù)編譯后會(huì)在函數(shù)名前面加上"@"前綴，在函數(shù)名后加上"@"和參數(shù)的字節(jié)數(shù)。
#define CALLBACK __stdcall
#define WINAPI __stdcall
#define WINAPIV __cdecl
#define APIENTRY WINAPI
#define APIPRIVATE __stdcall
#define PASCAL __stdcall
#define cdecl _cdecl
#ifndef CDECL
#define CDECL _cdecl
#endif
幾乎我們寫(xiě)的每一個(gè)WINDOWS API函數(shù)都是__stdcall類型的，為什么？？
首先，我們談一下兩者之間的區(qū)別：
WINDOWS的函數(shù)調(diào)用時(shí)需要用到棧（STACK，一種先入后出的存儲(chǔ)結(jié)構(gòu)）。當(dāng)函數(shù)調(diào)用完成后，棧需要清楚，這里就是問(wèn)題的關(guān)鍵，如何清除？？
如果我們的函數(shù)使用了_cdecl，那么棧的清除工作是由調(diào)用者，用COM的術(shù)語(yǔ)來(lái)講就是客戶來(lái)完成的。這樣帶來(lái)了一個(gè)棘手的問(wèn)題，不同的編譯器產(chǎn)生棧的方式不盡相同，那么調(diào)用者能否正常的完成清除工作呢？答案是不能。
如果使用__stdcall，上面的問(wèn)題就解決了，函數(shù)自己解決清除工作。所以，在跨（開(kāi)發(fā)）平臺(tái)的調(diào)用中，我們都使用__stdcall（雖然有時(shí)是以WINAPI的樣子出現(xiàn)），如JNI。
那么為什么還需要_cdecl呢？當(dāng)我們遇到這樣的函數(shù)如fprintf()它的參數(shù)是可變的，不定長(zhǎng)的，被調(diào)用者事先無(wú)法知道參數(shù)的長(zhǎng)度(如 typedef int (*MYPROC)(LPTSTR, ...); )，事后的清除工作也無(wú)法正常的進(jìn)行，因此，這種情況我們只能使用_cdecl。
到這里我們有一個(gè)結(jié)論，如果你的程序中沒(méi)有涉及可變參數(shù)，最好使用__stdcall關(guān)鍵字。
1.__cdecl
這是編譯器默認(rèn)的函數(shù)調(diào)用轉(zhuǎn)換方式，它可以處理可變參數(shù)的函數(shù)調(diào)用。參數(shù)
的入棧順序是從右向左。在函數(shù)運(yùn)行結(jié)束后，由調(diào)用函數(shù)負(fù)責(zé)清理入棧的參數(shù)。
在編譯時(shí)，在每個(gè)函數(shù)前面加上下劃線(_)，沒(méi)有函數(shù)名大小寫(xiě)的轉(zhuǎn)換。即
_functionname
2.__fastcall
有一些函數(shù)調(diào)用的參數(shù)被放入ECX，EDX中，而其它參數(shù)從右向左入棧。被調(diào)用
函數(shù)在它將要返回時(shí)負(fù)責(zé)清理入棧的參數(shù)。在內(nèi)嵌匯編語(yǔ)言的時(shí)候，需要注意
寄存器的使用，以免與編譯器使用的產(chǎn)生沖突。函數(shù)名字的轉(zhuǎn)換是：
@functionname@number
沒(méi)有函數(shù)名大小寫(xiě)的轉(zhuǎn)換，number表示函數(shù)參數(shù)的字節(jié)數(shù)。由于有一些參數(shù)不
需要入棧，所以這種轉(zhuǎn)換方式會(huì)在一定程度上提高函數(shù)調(diào)用的速度。
3.__stdcall
函數(shù)參數(shù)從右向左入棧，被調(diào)用函數(shù)負(fù)責(zé)入棧參數(shù)的清理工作。函數(shù)名轉(zhuǎn)換格
式如下：
聯(lián)系客服
