• <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>

            ivy-jie

            progress ...

            C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              9 Posts :: 41 Stories :: 6 Comments :: 0 Trackbacks

            (1) _stdcall調(diào)用
            _stdcall是Pascal程序的缺省調(diào)用方式,參數(shù)采用從右到左的壓棧方式,被調(diào)函數(shù)自身在返回前清空堆棧。
            WIN32 Api都采用_stdcall調(diào)用方式,這樣的宏定義說明了問題:

              #define WINAPI _stdcall

              按C編譯方式,_stdcall調(diào)用約定在輸出函數(shù)名前面加下劃線,后面加“@”符號(hào)和參數(shù)的字節(jié)數(shù),形如_functionname@number

            (2) _cdecl調(diào)用
            _cdecl是C/C++的缺省調(diào)用方式,參數(shù)采用從右到左的壓棧方式,傳送參數(shù)的內(nèi)存棧由調(diào)用者維護(hù)。_cedcl約定的函數(shù)只能被C/C++調(diào)用,每一個(gè)調(diào)用它的函數(shù)都包含清空堆棧的代碼,所以產(chǎn)生的可執(zhí)行文件大小會(huì)比調(diào)用_stdcall函數(shù)的大。

              由于_cdecl調(diào)用方式的參數(shù)內(nèi)存棧由調(diào)用者維護(hù),所以變長(zhǎng)參數(shù)的函數(shù)能(也只能)使用這種調(diào)用約定。關(guān)于C/C++中變長(zhǎng)參數(shù)(…)的問題,筆者將另文詳述。

              由于Visual C++默認(rèn)采用_cdecl 調(diào)用方式,所以VC中中調(diào)用DLL時(shí),用戶應(yīng)使用_stdcall調(diào)用約定。
            按C編譯方式,_cdecl調(diào)用約定僅在輸出函數(shù)名前面加下劃線,形如_functionname。

              (3) _fastcall調(diào)用
            _fastcall調(diào)用較快,它通過CPU內(nèi)部寄存器傳遞參數(shù)。

              按C編譯方式,_fastcall調(diào)用約定在輸出函數(shù)名前面加“@”符號(hào),后面加“@”符號(hào)和參數(shù)的字節(jié)數(shù),形如@functionname@number。

            ------------------------------------------------------------------------------------------------------------

            _cdecl是C和C++程序的缺省調(diào)用方式。每一個(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ù)。這兩個(gè)關(guān)鍵字看起來似乎很少和我們打交道,但是看了下面的定義(來自windef.h),你一定會(huì)覺得驚訝:   
            #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    
            幾乎我們寫的每一個(gè)WINDOWS API函數(shù)都是__stdcall類型的,為什么??

            首先,我們談一下兩者之間的區(qū)別:      
            WINDOWS的函數(shù)調(diào)用時(shí)需要用到棧(STACK,一種先入后出的存儲(chǔ)結(jié)構(gòu))。當(dāng)函數(shù)調(diào)用完成后,棧需要清除,這里就是問題的關(guān)鍵,如何清除??      
            如果我們的函數(shù)使用了_cdecl,那么棧的清除工作是由調(diào)用者,用COM的術(shù)語來講就是客戶來完成的。這樣帶來了一個(gè)棘手的問題,不同的編譯器產(chǎn)生棧的方式不盡相同,那么調(diào)用者能否正常的完成清除工作呢?答案是不能。      
            如果使用__stdcall,上面的問題就解決了,函數(shù)自己解決清除工作。所以,在跨(開發(fā))平臺(tái)的調(diào)用中,我們都使用__stdcall(雖然有時(shí)是以WINAPI的樣子出現(xiàn))。       那么為什么還需要_cdecl呢?當(dāng)我們遇到這樣的函數(shù)如fprintf()它的參數(shù)是可變的,不定長(zhǎng)的,被調(diào)用者事先無法知道參數(shù)的長(zhǎng)度,事后的清除工作也無法正常的進(jìn)行,因此,這種情況我們只能使用_cdecl。       到這里我們有一個(gè)結(jié)論,如果你的程序中沒有涉及可變參數(shù),最好使用__stdcall關(guān)鍵字    

            posted on 2009-05-23 18:38 ivy-jie 閱讀(2247) 評(píng)論(5)  編輯 收藏 引用

            Feedback

            # re: _stdcall和_cdec區(qū)別 2012-05-29 10:57 任騰
            “如果我們的函數(shù)使用了_cdecl,那么棧的清除工作是由調(diào)用者,用COM的術(shù)語來講就是客戶來完成的。這樣帶來了一個(gè)棘手的問題,不同的編譯器產(chǎn)生棧的方式不盡相同,那么調(diào)用者能否正常的完成清除工作呢?答案是不能。”
            問一下,為什么答案是不能?自己產(chǎn)生的堆棧為什么不能自己清除?
              回復(fù)  更多評(píng)論
              

            # re: _stdcall和_cdec區(qū)別 2012-06-18 21:12 Honwhy
            使用者在另外一個(gè)線程中。@任騰
              回復(fù)  更多評(píng)論
              

            # re: _stdcall和_cdec區(qū)別 2012-08-22 18:43 zwxhbxf
            當(dāng)我們遇到這樣的函數(shù)如fprintf()它的參數(shù)是可變的,不定長(zhǎng)的,被調(diào)用者事先無法知道參數(shù)的長(zhǎng)度,事后的清除工作也無法正常的進(jìn)行,因此,這種情況我們只能使用_cdecl。  回復(fù)  更多評(píng)論
              

            # re: _stdcall和_cdec區(qū)別 2012-08-22 18:48 zwxhbxf
            清除工作也無法正常的進(jìn)行不是一種缺陷嗎?難得不管它?  回復(fù)  更多評(píng)論
              

            # re: _stdcall和_cdec區(qū)別 2012-09-03 13:34 wd
            @任騰因?yàn)槎褩V羔樖接烧{(diào)用者push而減小 所以 只有調(diào)用才知道壓入了多少數(shù)據(jù)%esp要addl多少才能返回之前的調(diào)用狀態(tài)
              回復(fù)  更多評(píng)論
              


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            国内精品伊人久久久久妇| 亚洲成色WWW久久网站| 久久九九精品99国产精品| 久久午夜综合久久| 欧美日韩成人精品久久久免费看| 久久中文精品无码中文字幕| 久久93精品国产91久久综合| 国产精品午夜久久| 免费国产99久久久香蕉| 一级做a爰片久久毛片人呢| 亚洲国产成人久久精品影视| 久久国产精品久久精品国产| 国产成人久久AV免费| 99久久超碰中文字幕伊人| 国产精品美女久久久久AV福利| 久久996热精品xxxx| 亚洲国产成人久久笫一页| 久久人人爽人人人人爽AV| 久久无码人妻一区二区三区午夜 | A级毛片无码久久精品免费| 久久亚洲AV永久无码精品| 久久99热这里只频精品6| 久久精品水蜜桃av综合天堂| 国产精品免费久久久久电影网| 久久99精品国产麻豆宅宅| 久久国产免费直播| 精品国产91久久久久久久a| 久久亚洲国产精品123区| 久久久久久人妻无码| 狠狠色综合久久久久尤物| 久久亚洲精品无码观看不卡| 中文字幕久久精品无码| 亚洲精品白浆高清久久久久久| aaa级精品久久久国产片| 国产伊人久久| 国产V综合V亚洲欧美久久| 亚洲国产高清精品线久久| 三上悠亚久久精品| 精品国产乱码久久久久软件| 国产精品欧美亚洲韩国日本久久 | 久久91精品国产91久久麻豆|