青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

隨筆 - 20, 文章 - 0, 評論 - 45, 引用 - 0
數據加載中……

函數調用的區別:_cdecl以及_stdcall

一、概念
1)_stdcall調用
   _stdcall是Pascal程序的缺省調用方式,參數采用從右到左的壓棧方式,由調用者完成壓棧操作,被調函數自身在返回前清空堆棧。
   WIN32 Api都采用_stdcall調用方式,這樣的宏定義說明了問題:  #define WINAPI _stdcall
  
   按C編譯方式,_stdcall調用約定在輸出函數名前面加下劃線,后面加“@”符號和參數的字節數,形如_functionname@number.
   Therefore, the function declared as int func( int a, double b ) is decorated as follows: _func@12.
   按C++編譯方式,可參看(三)

 2)_cdecl調用
  
_cdecl是C/C++的缺省調用方式,參數采用從右到左的壓棧方式,由調用者完成壓棧操作 ,傳送參數的內存棧由調用者維護。
   _cedcl約定的函數只能被C/C++調用
,每一個調用它的函數都包含清空堆棧的代碼,所以產生的可執行文件大小會比調用_stdcall函數的大。
   按C編譯方式,_cdecl調用約定僅在輸出函數名前面加下劃線,形如_functionname。
   按C++編譯方式,可參看(三)

二、區別
     幾乎我們寫的每一個WINDOWS API函數都是__stdcall類型的,首先,需要了解兩者之間的區別: WINDOWS的函數調用時需要用到棧(STACK,一種先入后出的存儲結構)。當函數調用完成后,棧需要清除,這里就是問題的關鍵,如何清除?如果我 們的函數使用了_cdecl,那么棧的清除工作是由調用者,用COM的術語來講就是客戶來完成的。這樣帶來了一個棘手的問題,不同的編譯器產生棧的方式不 盡相同,那么調用者能否正常的完成清除工作呢?答案是不能。如果使用__stdcall,上面的問題就解決了,函數自己解決清除工作。所以,在跨(開發) 平臺的調用中,我們都使用__stdcall(雖然有時是以WINAPI的樣子出現)。那么為什么還需要_cdecl呢?當我們遇到這樣的函數如 fprintf()它的參數是可變的,不定長的,被調用者事先無法知道參數的長度,事后的清除工作也無法正常的進行,因此,這種情況我們只能使用 _cdecl。到這里我們有一個結論,如果你的程序中沒有涉及可變參數,最好使用__stdcall關鍵字。

三、編譯時函數名修飾約定規則
1)首先介紹一下函數修飾名,C” 或者“C++”函數在內部(編譯和鏈接)通過修飾名識別。修飾名是編譯器在編譯函數定義或者原型時生成的字符串。有些情況下使用函數的修飾名是必要的,如 在模塊定義文件里頭指定輸出“C++”重載函數、構造函數、析構函數,又如在匯編代碼里調用“C””或“C++”函數等。修飾名由函數名、類名、調用約定、返回類型、參數等共同決定。名字修飾約定隨調用約定和編譯種類(C或C++)的不同而變化。函數名修飾約定隨編譯種類和調用約定的不同而不同。下面詳細說明在C++編譯器中修飾名的約定方法,在C編譯器中的變化已經在(一)中闡述。

2)C++編譯時函數名修飾約定規則
    __stdcall調用約定:
  1)、以"?"標識函數名的開始,后跟函數名;
  2)、函數名后面以"@@YG"標識參數表的開始,后跟參數表;
  3)、參數表以代號表示:
  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"代表一次重復;
  4)、參數表的第一項為該函數的返回值類型,其后依次為參數的數據類型,指針標識在其所指數據類型前;
  5)、參數表后以"@Z"標識整個名字的結束,如果該函數無參數,則以"Z"標識結束。
  其格式為"?functionname@@YG*****@Z"或"?functionname@@YG*XZ",例如   int Test1(char *var1,unsigned long)-----“?Test1@@YGHPADK@Z”   void Test2() -----“?Test2@@YGXXZ
  __cdecl調用約定:
  規則同上面的_stdcall調用約定,只是參數表的開始標識由上面的"@@YG"變為"@@YA"。

四、在C++編譯時,引入c庫里面的函數的處理
    如果Add(int a, int b)是在c語言編譯器編譯,而在c++文件使用,由(三)知,因為c編譯器和c++編譯器對函數名的解釋不一樣(c++編譯器解釋函數名的時候要考慮函數參數,這樣是了方便函數重載,而在c語言中不存在函數重載的問題),會出現鏈接錯誤。 哪么該如何處理呢?這是關鍵字extern就派上用場了。
   而在c++文件使用c編譯器編譯過的函數,則需要在c++文件中聲明:extern "C" Add(int a, int b),使用extern "C",實質就是告訴c++編譯器,該函數是c庫里面的函數。請保持我的名稱,不要給我生成用于鏈接的函數修飾名。
   另外順便說一下extern的另一個用途,extern可以置于變量或者函數前,以標示變量或者函數的定義在別的文件中,提示編譯器遇到此變量和函數時在其他模塊中尋找其定義。#inlcude "***.***"     和 int   f()  等價于   extern int f() ;即 extern 申明的函數前不需要加引用頭文件就能用。

參考文獻:
博客:http://www.cnblogs.com/Winston/archive/2008/09/11/1289391.html










posted on 2011-04-19 13:23 Kenny Jiang 閱讀(9966) 評論(12)  編輯 收藏 引用 所屬分類: C++

評論

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

其實,從設計角度上說,還是覺得__cdecl 合理些,誰創建誰銷毀
2011-04-19 15:30 | 溪流

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

@溪流
_cdecl是由調用者銷毀的。不同的編譯器產生棧的方式不盡相同,所以在跨語言時是不適用的。
2011-04-19 17:57 | Kenny Jiang

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

@Kenny Jiang
這怎么說?壓棧工作難道不是主調函數做的?
2011-04-19 22:54 | 溪流

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

說得 亂七八糟 完全不對 什么叫不同編譯器產生棧不同 我沒見過..都是內存 沒有不同的 大部分語言都可以指定調用方式 只要知道調用約定 _stdcall和_cdecl 沒區別 使用 _stdcall只是默認規則而已 另外 Pascal的默認調用約定是_fastcall 最新版本的vs 則更加亂 ecx esi edi eax edx 都會拿來傳參
2011-04-20 02:53 | Lo

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

@Lo
額,我們的程序能夠正常運行都是編譯器的功勞,每種語言都有自己的編譯器,而且不止一種,如c++有gcc,vs等。他們的約定方式不同,所以如果用vs調用gcc編譯產生的庫,那么vs可能不能正確釋放gcc的棧,所以跨平臺時,建議是函數本身釋放這些空間,而不是調用者,即_stdcall方式。
2011-04-20 12:43 | Kenny Jiang

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

@溪流
你可以詳細看看博客,這個是有區別的。
2011-04-20 12:47 | Kenny Jiang

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

@Lo
fastcall不就是拿寄存器來傳的。不過到了64位下面,stdcall啊cdecl啊這些亂七八糟的東西都被取消了,全部做成fastcall。但是你stdcall仍然可以使用,就是會被當成fastcall來編譯了。

而且stdcall啊cdecl啊fastcall啊都是跟編譯器無關的協議,不會受到不同編譯器的影響的。不然gcc怎么調用windows api?
2011-04-20 13:21 | 陳梓瀚(vczh)

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

@Kenny Jiang
你可以仔細看看我的回復以及樓上,我覺得你理解的有問題
2011-04-20 13:33 | 溪流

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

@陳梓瀚(vczh)
恩,你說的對。
gcc能調用win api是因為win api缺省都是_stdcall,由被調者銷毀堆棧。如果是cdecl那么就會出現問題。而C++/c缺省是cdecl,所以在導出函數接口時(如自己寫的DLL),需要特別強調是_stdcall才可以被別的語言正常使用。
2011-04-20 17:11 | Kenny Jiang

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

@溪流
呵呵,壓棧是主調函數做的,但是出棧就不同了。
一點都不給博主點面子,回復很犀利,呵呵。
2011-04-20 17:12 | Kenny Jiang

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

@Kenny Jiang
正因為壓棧是主調函數做的,所以,如果存在你說的“編譯器不同導致‘棧不同’”的問題,出棧工作不是應該同樣由主調函數承擔才不至于出問題嗎?所以從這一點上說,__cdecl 顯得更合理。
其他的,是否語言間能互相識別,只要遵循同樣的調用約定就可以了,不存在某種調用約定的特殊優勢。

2011-04-20 20:55 | 溪流

# re: 函數調用的區別:_cdecl以及_stdcall  回復  更多評論   

http://msdn.microsoft.com/en-us/library/zxk0tw93%28v=vs.71%29.aspx
2013-07-17 10:52 | paster
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            欧美日韩1区2区3区| 国产精品美女久久久免费| 麻豆精品一区二区av白丝在线| 国产偷久久久精品专区| 亚洲伊人一本大道中文字幕| 国产亚洲成年网址在线观看| 欧美日韩一区在线视频| 欧美黄色影院| 欧美日韩不卡合集视频| 欧美日韩国产综合视频在线| 嫩草成人www欧美| 嫩草伊人久久精品少妇av杨幂| 免费亚洲网站| 国产精品久久久久久久久搜平片| 欧美视频观看一区| 国产综合久久久久影院| 在线看国产日韩| 一本一道久久综合狠狠老精东影业| 亚洲乱码国产乱码精品精98午夜| 99在线|亚洲一区二区| 午夜精品成人在线| 欧美激情一区二区三区全黄| 日韩天堂在线视频| 久久在线免费观看视频| 国产精品国产三级国产普通话三级 | 一区二区三区国产在线| 久久精品国产亚洲5555| 欧美日韩亚洲综合一区| 亚洲成人在线观看视频| 一本色道综合亚洲| 国产精品美腿一区在线看| 国产精品一级久久久| 国际精品欧美精品| 在线观看欧美激情| 亚洲男人的天堂在线aⅴ视频| 欧美激情二区三区| 久久成人精品电影| 久久久久国产一区二区| 欧美人成在线视频| 国产三区精品| 亚洲香蕉成视频在线观看| 麻豆精品传媒视频| 亚洲视频在线播放| 欧美精品日本| 国产一区二区成人| 夜夜嗨av一区二区三区免费区| 欧美在线免费观看| 欧美一区二区三区精品电影| 欧美日韩在线视频一区| 国内精品福利| 久久综合色88| 久久婷婷麻豆| 亚洲电影有码| 欧美淫片网站| 久久国产视频网站| 亚洲电影在线播放| 免费亚洲婷婷| 午夜精品久久久久99热蜜桃导演| 久久亚洲图片| 久久全球大尺度高清视频| 国产日韩欧美一区二区| 久久疯狂做爰流白浆xx| 午夜精品福利一区二区三区av| 亚洲国产欧美在线| 亚洲欧美日韩电影| 狠狠做深爱婷婷久久综合一区 | 久久视频在线视频| 国产精品99久久久久久www| 国产麻豆日韩欧美久久| 久久综合久久久| 久久人人爽人人爽| 香蕉免费一区二区三区在线观看| 先锋影音久久久| 国语精品中文字幕| 亚洲日本中文| 国产亚洲精品久久久| 久久经典综合| 欧美在线视频在线播放完整版免费观看 | 亚洲在线视频免费观看| 国产女主播在线一区二区| 久久女同互慰一区二区三区| 日韩视频不卡中文| 欧美一区二区三区在线播放| 99亚洲一区二区| 女同性一区二区三区人了人一| 在线视频一区二区| 欧美风情在线| 久久夜色精品国产噜噜av| 国产精品免费在线| 亚洲婷婷在线| 欧美视频一区二| 久久精品国产2020观看福利| 欧美手机在线视频| 日韩写真视频在线观看| 日韩香蕉视频| 欧美日韩国产片| 免费不卡视频| 在线播放豆国产99亚洲| 午夜在线成人av| 国产区在线观看成人精品| 亚洲福利国产| 日韩视频三区| 欧美日韩在线播放一区二区| 欧美风情在线观看| 一区二区三区产品免费精品久久75 | 久久国产精品高清| 欧美一区二区三区久久精品| 国产精品你懂的| 久久综合中文| 免费观看成人www动漫视频| 亚洲美女av电影| 99热免费精品在线观看| 亚洲精品自在久久| 国产欧美日韩伦理| 欧美高清你懂得| 香蕉久久久久久久av网站| 老司机67194精品线观看| 亚洲精品乱码久久久久久久久| 欧美激情va永久在线播放| 午夜国产不卡在线观看视频| 蜜臀99久久精品久久久久久软件| 亚洲人成人一区二区三区| 国产一区二区三区久久悠悠色av | 欧美性色视频在线| 欧美日韩精品三区| 欧美日韩成人综合天天影院| 另类亚洲自拍| 欧美精品 日韩| 欧美—级高清免费播放| 欧美1区3d| 久久激五月天综合精品| 久久在线视频| 欧美日韩免费高清| 国产欧美一区二区三区视频| 国产午夜精品久久久久久久| 国产麻豆视频精品| 国产精品一区在线播放| 91久久久精品| 亚洲精品你懂的| 亚洲影视九九影院在线观看| 亚洲私人黄色宅男| 久久久999精品视频| 亚洲国产精品一区二区三区| 亚洲精品专区| 亚洲第一黄色| 在线观看视频亚洲| 日韩视频三区| 午夜免费日韩视频| 久久久久免费视频| 欧美激情视频一区二区三区在线播放| 老色鬼精品视频在线观看播放| 暖暖成人免费视频| 新67194成人永久网站| 国产一区二区精品久久91| 欧美亚洲视频在线看网址| 欧美一区二区福利在线| 欧美日韩精品不卡| 亚洲国产精品va| 久久久久久9999| 欧美日韩精品三区| 亚洲国产黄色片| 麻豆精品网站| 免费一级欧美片在线播放| 国产精品成av人在线视午夜片| 国产日韩欧美一区二区三区在线观看| 亚洲大胆女人| 亚洲第一福利社区| 久久手机免费观看| 国产自产女人91一区在线观看| 亚洲男人第一网站| 中日韩在线视频| 99re8这里有精品热视频免费 | 免播放器亚洲| 亚洲无吗在线| 国产欧美精品日韩精品| 香蕉久久夜色精品| 欧美亚洲一级片| 亚洲激情第一页| 中文日韩电影网站| 国产一区二区视频在线观看| 久久久夜夜夜| 欧美日韩一区二区视频在线观看| 亚洲电影视频在线| 日韩手机在线导航| 亚洲第一黄色| 亚洲男女毛片无遮挡| 激情综合色丁香一区二区| 亚洲国产91精品在线观看| 亚洲日韩欧美视频一区| 国产精品一区二区三区久久久| 久久免费视频在线| 国产精品久久久久9999| 欧美不卡三区| 一区在线视频观看| 最新国产拍偷乱拍精品| 欧美激情一区二区三区| 99热免费精品| 一区视频在线| 久久国产主播| 欧美激情中文不卡|