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

            天下

            記錄修行的印記

            Double Thunking


            By default, when compiling with /clr (not /clr:pure), the definition of a managed function causes the compiler to generate a managed entry point and a native 

            entry point. This allows the managed function to be called from native and managed call sites. However, when a native entry point exists, it can be the entry 
            point for all calls to the function. If a calling function is managed, the native entry point will then call the managed entry point. In effect, two calls 
            are required to invoke the function (hence, double thunking). For example, virtual functions are always called through a native entry point.
            One resolution is to tell the compiler not to generate a native entry point for a managed function, that the function will only be called from a managed 
            context, by using the __clrcall calling convention.
            Similarly, if you export (dllexport, dllimport) a managed function, a native entry point is generated and any function that imports and calls that function 
            will call through the native entry point. To avoid double thunking in this situation, do not use native export/import semantics; simply reference the 
            metadata via #using (see The #using Directive).
            In Visual C++ 2005 the compiler was updated to reduce unnecessary double thunking. For example, any function with a managed type in the signature (including 
            return type) will implicitly be marked as __clrcall. For more information on double thunk elimination, see 
            http://msdn.microsoft.com/msdnmag/issues/05/01/COptimizations/default.aspx.
            Example
            The following sample demonstrates double thunking. When compiled native (without /clr), the call to the virtual function in main generates one call to T's 
            copy constructor and one call to the destructor. Similar behavior is achieved when the virtual function is declared with /clr and __clrcall. However, when 
            just compiled with /clr, the function call generates a call to the copy constructor but there is another call to the copy constructor due to the 
            native-to-managed thunk.
            純 MSIL 程序集可以調用非托管函數,但不能由非托管函數調用。因此,與非托管函數使用的服務器代碼相比,純 MSIL 更適合于使用非托管函數的客戶端代碼。
            當我們使用/clr選項(不是/clr:pure)進行編譯的時候,一個托管函數(managed function),會導致編譯器生成一個托管的入口點(managed entry point)和一個原生的入口點
            (native entry point),這樣可以使得托管函數既可以被托管代碼調用,也可以被原生代碼調用。但是,當一個原生的入口點存在的時候,它將成為所有調用的入口點。也就是說
            如果調用者是托管的,它還是會先去調用原生入口點,然后原生的入口點再去調用托管的入口點,這就意味著調用了兩次函數入口點(Double Thunking)。 



            c++ cli 標準

            posted on 2015-12-01 11:14 天下 閱讀(333) 評論(0)  編輯 收藏 引用 所屬分類: C#

            <2011年2月>
            303112345
            6789101112
            13141516171819
            20212223242526
            272812345
            6789101112

            導航

            統計

            常用鏈接

            留言簿(4)

            隨筆分類(378)

            隨筆檔案(329)

            鏈接

            最新隨筆

            搜索

            最新評論

            波多野结衣AV无码久久一区| 久久亚洲中文字幕精品一区| 久久亚洲精品无码AV红樱桃| 精品国产乱码久久久久久1区2区| 国产精品99精品久久免费| 久久九九亚洲精品| 久久久WWW成人| 亚洲AV无码久久精品成人| 99久久夜色精品国产网站| 久久久久久精品无码人妻| 久久精品国产精品青草| 亚洲国产精品狼友中文久久久| 国产亚洲精品美女久久久| 久久精品不卡| 中文字幕一区二区三区久久网站| 久久婷婷午色综合夜啪| 亚洲狠狠久久综合一区77777| 免费一级欧美大片久久网| 97热久久免费频精品99| 国产成人精品三上悠亚久久| 久久精品国产欧美日韩| 国内精品久久久久| 久久久久久亚洲Av无码精品专口| 狠狠色丁香久久婷婷综合_中| 国产精品成人99久久久久91gav| 日产精品久久久久久久性色| 久久精品一区二区三区AV| 亚洲国产婷婷香蕉久久久久久| 成人国内精品久久久久影院VR| 97久久精品人妻人人搡人人玩| 99久久精品免费看国产一区二区三区 | 国产激情久久久久影院老熟女免费 | 色婷婷综合久久久久中文字幕| 久久精品国产亚洲av水果派| 婷婷五月深深久久精品| 亚洲综合日韩久久成人AV| 久久久噜噜噜久久中文字幕色伊伊 | 99久久国产综合精品网成人影院| 国产99精品久久| 嫩草影院久久国产精品| 国产精品成人无码久久久久久|