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

            醬壇子

            專注C++技術(shù) 在這里寫下自己的學(xué)習(xí)心得 感悟 和大家討論 共同進步(歡迎批評?。。。?/p>

              C++博客 :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
              66 Posts :: 16 Stories :: 236 Comments :: 0 Trackbacks

            公告

            王一偉 湖南商學(xué)院畢業(yè) 電子信息工程專業(yè)

            常用鏈接

            留言簿(19)

            我參與的團隊

            搜索

            •  

            積分與排名

            • 積分 - 387987
            • 排名 - 64

            最新隨筆

            最新評論

            閱讀排行榜

            評論排行榜

            轉(zhuǎn)自:CSDN?? 自己做記錄? 大家不要砸磚頭 明年中旬研究這塊


            什么是C++/CLI呢?C++當然指的是Bjarne Stroustrup在BELL實驗室發(fā)明的C++語言,它實現(xiàn)了運行時取得速度和尺寸最佳化的靜態(tài)對象模型,然而它除了堆分配外不支持程序的動態(tài)修改,它準許無限地接近底層設(shè)備,但在程序運行過程中幾乎無法操作活動類型,也無法操作與程序相關(guān)聯(lián)的底層結(jié)構(gòu)。Herb Sutter,C++/CLI的主要構(gòu)造者之一,稱C++是一門“混凝土”式的語言。

              CLI指的是通用語言結(jié)構(gòu),一種支持動態(tài)組件編程模型的多重結(jié)構(gòu),在許多情況下,這代表了一個與C++對象模型完全顛倒了的模式。一個時實的軟件層,有效地執(zhí)行系統(tǒng),在底層操作系統(tǒng)與程序之間運行。操作底層的設(shè)備受到一定的限制,操作執(zhí)行程序中的活動類型及與程序相關(guān)聯(lián)的下部結(jié)構(gòu)得到了支持。反斜杠(/)代表C++和CLI的捆綁,這個捆綁帶來的細節(jié)問題是本文主要討論的問題。

              所以,“什么是C++/CLI”問題的最初、最接近答案是:它是靜態(tài)C++對象模型到CLI的動態(tài)組件對象編程模型的捆綁。簡而言之,它就是你如何用C++在.NET中編程,而不是C#或Visual Basic.NET。象C#和CLI本身一樣,C++/CLI正在ECMA(歐洲計算機制造商協(xié)會)主持下進行標準化,以最終符合ISO標準。

              實時通用語言(CLR)是CLI的微軟版本,它非常適用于微軟的Windows操作系統(tǒng),相似地,Visual C++2005是C++/CLI的實現(xiàn)。

              作為第二個近似的答案,我認為C++/CLI是.NET編程模式與C++的結(jié)合,正如以前將模板與C++結(jié)合起來產(chǎn)生的泛型編程。所有這種結(jié)合中,企業(yè)所擁有的C++的投資以及開發(fā)人員使用C++的經(jīng)驗將得到保存,而這恰恰是使用C++/CLI進行開發(fā)的重要基礎(chǔ)。

              閱讀導(dǎo)航

              學(xué)習(xí)C++/CLI的方法
              在設(shè)計C++/CLI語言中涉及三個方面問題,這同樣貫徹于所有的其他程序開發(fā)語言:一是語言級的語法向底層通用類型系統(tǒng)(簡稱CTS)的映射;二是向程序開發(fā)人員提供的CLI的底層細節(jié)結(jié)構(gòu)的級別選擇;三是超越CLI的直接支持,提供額外的功能性函數(shù)的選擇。

              從C++/CLI到CTS的映射?
              使用C++/CLI編程時間了解底層的CTS非常重要。CTS包括以下三種常用類的類型:

              1、多態(tài)引用類型,這正是對于所有繼承類所要使用的。

              2、非多態(tài)值類型,這用于實時高效的具體類型,例如數(shù)值類型。

              3、抽象的接口類型,這用于定義一個操作集,也可以用于實現(xiàn)接口的引用或值類型集合。

              CLI的細節(jié)
              設(shè)計一個CLI語言時第二個必須要考慮的問題是將CLI的底層執(zhí)行模式融入到語言的細節(jié)級別。這種語言用于解決什么問題?這種語言是否有必須的工具來解決這些問題?這種語言可能吸引什么樣的程序開發(fā)人員?

              存在的問題
              在垃圾收集器掃描緊縮狀態(tài)下,位于托管堆上的任何對象非??赡苊鎸χ匦露ㄎ粏栴}。指向?qū)ο蟮闹羔樋梢詫崟r跟蹤并修改。開發(fā)人員不能自己手動跟蹤,所以,如果你獲許取得一個可能位于托管堆上的值類型的地址時,除了本地指針外,還需要有一個跟蹤形態(tài)的指針。

              額外增加的功能
              在垃圾收集器掃描緊縮狀態(tài)下,位于托管堆上的任何對象非??赡苊鎸χ匦露ㄎ粏栴}。指向?qū)ο蟮闹羔樋梢詫崟r跟蹤并修改。開發(fā)人員不能自己手動跟蹤,所以,如果你獲許取得一個可能位于托管堆上的值類型的地址時,除了本地指針外,還需要有一個跟蹤形態(tài)的指針。

              小結(jié)

              C++/CLI代表托管與本地編程的結(jié)合,這種綜合已經(jīng)通過元級相對獨立但又相互平等地組件和二進制元素得到了完成,包括混合模式(本地和CTS類型的元級混合,還有一個本地及CLI對象文件的二進制混合),純模式(本地和CTS類型的源代碼級混合,所有的都被編譯為CLI對象文件),本地分類(可以通過一個特定的打包類來保持CTS類型),和CTS分類(可以保持本地類型為指針)。

              當然,C++/CLI開發(fā)人員也可以單獨使用CLI類型來編程,并通過這種方式來提供伺服狀態(tài)下的可校驗代碼,例如可以作為SQL Server2005的一個SQL存儲過程。

              現(xiàn)在,還是回到這個問題上來,什么是C++/CLI?它是進行.NET編程模式的最佳切入點。對于C++/CLI,有一個來自C++的遷移路徑,它不僅包含C++的底層基礎(chǔ),而且也需要C++編程經(jīng)驗,對于這些,我感到非常滿意。

              學(xué)習(xí)C++/CLI的方法

              在設(shè)計C++/CLI語言中涉及三個方面問題,這同樣貫徹于所有的其他程序開發(fā)語言:一是語言級的語法向底層通用類型系統(tǒng)(簡稱CTS)的映射;二是向程序開發(fā)人員提供的CLI的底層細節(jié)結(jié)構(gòu)的級別選擇;三是超越CLI的直接支持,提供額外的功能性函數(shù)的選擇。

              第一條對于所有的CLI語言來說都大致相同,第二條和第三條對于不同的CLI語言來說是不同的,相互區(qū)別的。根據(jù)你需要解決什么樣的問題,你將選擇這種或那種語言,也有可能混合使用多種CLI語言。學(xué)習(xí)C++/CLI涉及到了解它在設(shè)計過程中的所有這些涉及方面。

              從C++/CLI到CTS的映射?

              使用C++/CLI編程時間了解底層的CTS非常重要。CTS包括以下三種常用類的類型:

              1、多態(tài)引用類型,這正是對于所有繼承類所要使用的。

              2、非多態(tài)值類型,這用于實時高效的具體類型,例如數(shù)值類型。

              3、抽象的接口類型,這用于定義一個操作集,也可以用于實現(xiàn)接口的引用或值類型集合。

              這個設(shè)計方面的問題,即將CTS映射到語言內(nèi)建的數(shù)據(jù)類型集合,通常同樣貫穿于所有的CLI語言,雖然不同的CLI語言語法不同。所以,在C#中你可能這么寫:

            abstract class Shape { ... } // C#

              來定義了一個Shape基類,從該類將導(dǎo)出幾何對象,然而在C++/CLI你將這么寫:

            ref class Shape abstract { ... }; // C++/CLI

              上述代碼說明了底層的C++/CLI引用類型。這兩種聲明在內(nèi)層代表的意思是一樣的。相似地,在C#中你這么寫:

            struct Point2D { ... } // C#

              來定義一個具體的Point2D 類,然而在C++/CLI中這么寫:

            value class Point2D { ... }; // C++/CLI

              C++/CLI支持的類型集合代表了CTS與本地設(shè)備的綜合,這決定了你的語法選擇,例如:

            class native {};
            value class V {};
            ref class R {};
            interface class I {};

              CTS也支持與本地列舉類型稍微不同的列舉類類型。當然,對于上述兩者CTS是都支持的。例如:

            enum native { fail, pass };
            enum class CLIEnum : char { fail, pass};

              相似地,CTS支持它本身的數(shù)組類型,并且它再一次將其與本地數(shù)組在行為上區(qū)分開來。同時,微軟再次為這兩種類型提供了支持。

            int native[] = { 1,1,2,3,5,8 };
            array<int>^ managed = { 1,1,2,3,5,8 };

              那種認為一種CLI語言比其他CLI語言在向底層的CTS映射中表現(xiàn)的更出色或更完美都是不確切的,相反,每種不同的CLI語言代表著對CTS底層對象模型的不同理解,在下一節(jié)你將更清楚地看到這一點。

              CLI的細節(jié)

              設(shè)計一個CLI語言時第二個必須要考慮的問題是將CLI的底層執(zhí)行模式融入到語言的細節(jié)級別。這種語言用于解決什么問題?這種語言是否有必須的工具來解決這些問題?這種語言可能吸引什么樣的程序開發(fā)人員?

              例如,值類型存在于托管堆上,在很多情況下值類型可以看到它們自身的存在。

              1、通過隱含的加箱操作,當一個值類型的實例被分配給一個對象或當一個虛擬的方法通過一個值類型來調(diào)用;

              2、當這個值類型被當作應(yīng)用引用類類型的成員時;

              3、當這個值類型 被當作CLI數(shù)組成員時;

              需要指出的是,這種情況下開發(fā)人員是否被允許操作值類型的地址是CLI語言設(shè)計時必須應(yīng)該予以考慮的問題。

              存在的問題

              在垃圾收集器掃描緊縮狀態(tài)下,位于托管堆上的任何對象非常可能面對重新定位問題。指向?qū)ο蟮闹羔樋梢詫崟r跟蹤并修改。開發(fā)人員不能自己手動跟蹤,所以,如果你獲許取得一個可能位于托管堆上的值類型的地址時,除了本地指針外,還需要有一個跟蹤形態(tài)的指針。

              銷售商考慮的是什么?那就是需要簡單和安全,在語言中直接提供跟蹤一個對象或集合的指針使語言復(fù)雜化,沒有這種支持,將減少復(fù)雜程度,可資利用的、潛在的程序開發(fā)人群可能會增加,此外,準許程序開發(fā)人員操作生命短暫的值類型,增加了錯誤產(chǎn)生的可能性,程序開發(fā)人員可能有意無意地對內(nèi)存進行錯誤操作,不支持跟蹤指針,一個潛在的更安全地實時環(huán)境產(chǎn)生了。

              另一方面,效率和靈活性也是必須考慮的一個問題,每一次向同一個對象分配值類型時,一個全新的數(shù)值加箱操作發(fā)生了,準許存取加箱值類型允許在內(nèi)存中進行更新,這可能在性能上產(chǎn)生了一個非常巨大的進步。沒有跟蹤形態(tài)的指針,你無法用指針算法重新聲明一個CLI數(shù)組,這意味著CLI數(shù)組不能使用標準模板庫進行重新聲明,也不能使用一般的算法。準許操作加箱數(shù)值使設(shè)計具有更大地靈活性。

              微軟在C++/CLI中選擇地址集合模式來處理托管堆上的值類型。

            int ival = 1024;
            int^ boxedi = ival;
            array<int>^ ia = gcnew array<int>{1,1,2,3,5,8};
            interior_ptr<int> begin = &ia[0];

            value struct smallInt { int m_ival; ... } si;
            pin_ptr<int> ppi = &si.m_ival;

              典型地C++/CLI開發(fā)人員是一個復(fù)雜的系統(tǒng)程序員,承擔著提供下層內(nèi)部構(gòu)造和有組織的應(yīng)用程序的任務(wù),而這些恰恰是未來商業(yè)發(fā)展的基礎(chǔ)。C++/CLI開發(fā)人員必須兼顧可測量性和可執(zhí)行性,所以必須在系統(tǒng)的高度級上來看待CLI下層結(jié)構(gòu)。CLI細節(jié)水平反映了開發(fā)人員的臉色。

              復(fù)雜性本身并不代表對質(zhì)量的否定,人類比單細胞細菌復(fù)雜的多,這當然不是一件壞事,然而,當表達一個簡單的概念變的復(fù)雜化后,這常常被認為是一件壞事。在C++/CLI中,CLI開發(fā)團隊已經(jīng)試著提供一種精巧的方法來表達方式一個復(fù)雜的事情。

              額外增加的功能

              第三個設(shè)計方面是特定功能性的語言層,它遠遠超過CLI所提供的直接支持,雖然這可能需要在語言層支持和CLI底層執(zhí)行模式間建立一個映射。但在某些情況下,這恰恰是不可能的,因為語言無法調(diào)節(jié)CLI的行為。這種情況的例子就是在基類的構(gòu)造及析構(gòu)函數(shù)中定義虛函數(shù)。根據(jù)ISO-C++在這種情況下的語言學(xué),需要用每一個基類的構(gòu)造和虛構(gòu)函數(shù)重新設(shè)置虛擬表,而這是不可能的,因為虛擬表句柄是實時管理的,而不是某一個語言來管理。

              所以,這個設(shè)計方面是在完美性和可行性之間的妥協(xié)產(chǎn)物,C++/CLI提供的額外功能主要表現(xiàn)在三個方面:

              1、獲取資源的一種形式是對于引用類型的初始化,此外,提供一種自動化工具,用于占用較少資源、所謂的可確定性自動消亡的垃圾收集類型對象。

              2、一種深度拷貝形式的語法與C++拷貝構(gòu)造函數(shù)和拷貝分配操作符相一致,但其并不適用與值類型。

              3、除了最初的一般性CLI機制外,還有對于CTS類型的C++模板直接支持。這些是我第一篇文章中討論的主題。此外,還提供了針對CLI類型的可校驗STL版本。

              讓我們來看一個簡單的例子,一個確定性消亡問題。在垃圾搜集器重新聲明一塊與對象相關(guān)聯(lián)的內(nèi)存之前,一個相關(guān)的消亡方法,如果存在的話,將被調(diào)用。你可以認為這種方法是超級析構(gòu)函數(shù),因為它與對象的程序生命期無關(guān)。這就叫做終結(jié)。終結(jié)函數(shù)是否調(diào)用以及什么時間調(diào)用都沒有明確規(guī)定,這就是垃圾收集器的非確定性終結(jié)。

              在動態(tài)內(nèi)存管理的情況下,非確定性終結(jié)工作非常好,當可用內(nèi)存變的越來越少時,垃圾收集器介入并開始著手解決問題。然而,非決定性終結(jié)也有工作不好的時候,當一個對象維護一個重要資源,例如一個數(shù)據(jù)庫連接、鎖定某些類別、或者可能是本地的堆內(nèi)存。在這種情況下,只要是不需要,應(yīng)立即釋放資源。目前CLI所支持的解決問題的方法是,對于一個類通過執(zhí)行IDisposable接口提供的Dispose方法釋放資源。這里的問題是執(zhí)行Dispose方法需要一個清晰的聲明,所以它也就不可能存在調(diào)用。

              最基本的C++中的設(shè)計模式是上述的通過初始化來獲取資源,這意味著類使用構(gòu)造函數(shù)來獲取資源,相反,類使用析構(gòu)函數(shù)來釋放資源。這些行為由類對象在生存期內(nèi)自動管理。

              下面是引用類釋放資源時所做的順序動作:

              1、 首先使用析構(gòu)函數(shù)來封裝所有與釋放類有關(guān)的資源時所必須的代碼;

              2、 析構(gòu)函數(shù)自動調(diào)用后,結(jié)束類對象的生命期。

              對于引用類型來說,CLI沒有類析構(gòu)函數(shù)的概念,所以析構(gòu)函數(shù)不得不映射為在底層執(zhí)行的其它代碼。此時,在內(nèi)部,編譯器執(zhí)行以下操作:

              1、 類讓其基類列表繼承自IDisposable接口;

              2、 析構(gòu)函數(shù)轉(zhuǎn)換成IDisposable的Dispose方法。

              以上實現(xiàn)了目標的一半,一種實現(xiàn)析構(gòu)造函數(shù)自動調(diào)用的方法仍然需要,對于引用類型,一種特殊的基于棧的符號得到支持,也就是說,一個對象的生命期與它的聲明范圍有關(guān)。在內(nèi)部,編譯器將符號轉(zhuǎn)換為在托管堆上分配引用對象。隨著作用域的終結(jié),編譯器插入一個Dispose方法-用戶定義的析構(gòu)函數(shù)。與對象有關(guān)的內(nèi)存的收回在垃圾收集器的控制下得到執(zhí)行。

              C++/CLI并不是將C++拓展到一個托管的世界,更確切的說,它代表一個完全綜合的范例,某種程度上就象當初將泛編程模式和多重繼承綜合進該語言一樣。我認為C++/CLI開發(fā)小組做了一項非常卓有成效的工作。

              小結(jié)

              C++/CLI代表托管和本地編程的結(jié)合。在反復(fù)過程中,這種綜合已經(jīng)通過源級相對獨立但又相互平等地組件和二進制元素得到了完成,包括混合模式(本地和CTS類型的源級混合,還有一個本地及CLI對象文件的二進制混合),純模式(本地和CTS類型的源代碼級混合,所有的都被編譯為CLI對象文件),本地分類(可以通過一個特定的打包類來保持CTS類型),和CTS分類(可以保持本地類型為指針)。

              當然,C++/CLI開發(fā)人員也可以單獨使用CLI類型來編程,并通過這種方式來提供伺服狀態(tài)下的可校驗代碼,例如可以作為SQL Server2005的一個SQL存儲過程。

              現(xiàn)在,還是回到這個問題上來,什么是C++/CLI?它是進行.NET編程模式的最佳切入點。對于C++/CLI,有一個來自C++的遷移路徑,它不僅包含C++的底層基礎(chǔ),而且也需要C++編程經(jīng)驗,對于這些,我感到非常滿意。
            posted on 2007-02-10 19:13 @王一偉 閱讀(3155) 評論(6)  編輯 收藏 引用

            Feedback

            # re: 完美的C++:C++/CLI 2007-02-10 21:22 gql
            完美?!??!  回復(fù)  更多評論
              

            # re: 完美的C++:C++/CLI 2007-02-11 22:46 江水獸
            原來就是傳說中的托管C++編程哪!

            我目前對這不太清楚 感覺自己級別還很不夠 也沒有做學(xué)習(xí).NET的準備 畢竟自己似乎沒有這個必要……

            但是文章依然收藏了 轉(zhuǎn)載得不錯!


              回復(fù)  更多評論
              

            # re: 完美的C++:C++/CLI 2007-02-13 14:25 斷了的貓
            放屁,把c++從編譯型語言硬搞成解釋型語言就完美了?在.net虛擬機里龜速運行就完美了?  回復(fù)  更多評論
              

            # re: 完美的C++:C++/CLI 2007-02-14 13:00 曉麗
            看了你的東西,我真郁悶.我看不明白!
            自己好渺小哦!真是慘兮!
            我要好好學(xué)習(xí),天天向上!  回復(fù)  更多評論
              

            # re: 完美的C++:C++/CLI 2007-02-14 19:03 wlw
            我覺得目前她的用處還是native向managed的一層wrap手段  回復(fù)  更多評論
              

            # re: 完美的C++:C++/CLI 2007-03-06 08:54 mymsdn
            @斷了的貓
            其實.NET編程中最后的運行第一次是慢的,但是之后的運行都是非常快的.(雖然和ISO-C++比相對弱一些,但是就它的開發(fā)速度和效率,可謂性價比善好)
            而且好像C++/CLI也不是解釋型語言啦.
            MS開發(fā)這個目標是讓C++程序員轉(zhuǎn)到.NET平臺的時候可以更快速輕松,MS并沒有太大的把握完全去取代ISO-C++,畢竟C++確實很牛.  回復(fù)  更多評論
              


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


            久久精品国产69国产精品亚洲| 亚洲AV无码久久精品成人| 一级做a爱片久久毛片| 嫩草影院久久国产精品| 狠狠久久综合伊人不卡| 亚洲一区精品伊人久久伊人| 久久久久av无码免费网| 久久久精品2019免费观看| 亚洲国产成人久久综合一| 久久精品国产99国产精品亚洲| 久久久久久毛片免费播放| 久久久亚洲精品蜜桃臀| 久久久久亚洲AV成人片 | 久久99精品久久久久久9蜜桃| 亚洲国产一成久久精品国产成人综合 | 色综合久久夜色精品国产| 7777久久亚洲中文字幕| 久久精品青青草原伊人| 久久久久久久亚洲精品| 久久精品九九亚洲精品| 久久精品国产精品亚洲精品| 蜜臀久久99精品久久久久久| 狠狠干狠狠久久| 久久水蜜桃亚洲av无码精品麻豆| 久久久国产精品| 国产精自产拍久久久久久蜜 | 国产精品久久久天天影视香蕉 | 久久电影网2021| 久久综合久久自在自线精品自| 亚洲国产天堂久久综合| 亚洲а∨天堂久久精品9966| 久久精品成人欧美大片| 99久久综合狠狠综合久久止| 日产精品99久久久久久| 99精品国产综合久久久久五月天| 久久综合九色综合久99| 久久精品综合一区二区三区| 久久97久久97精品免视看秋霞| 久久电影网| 亚洲国产日韩欧美久久| 亚洲精品乱码久久久久66|