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

            統(tǒng)計(jì)

            • 隨筆 - 50
            • 文章 - 42
            • 評(píng)論 - 147
            • 引用 - 0

            留言簿(6)

            隨筆分類

            文章分類

            Link

            搜索

            •  

            積分與排名

            • 積分 - 164717
            • 排名 - 159

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            【轉(zhuǎn)】C Runtime Library 的來(lái)歷, API, STL, MFC, ATL關(guān)系

             剛接觸Windows開發(fā)時(shí),為了快速入門查了不少資料,沒想到看的越多,腦袋越糊涂。因?yàn)閷懲环N功能的程序,找到的例程風(fēng)格截然不同。拿C程序來(lái)說(shuō),有些API的名稱都很長(zhǎng),都是沒見過(guò)的變量類型而且全大寫;有些跟熟悉的Linux環(huán)境C開發(fā)差不多,標(biāo)準(zhǔn)短小的C函數(shù)名。再比如某些C++程序,用的標(biāo)準(zhǔn)類也會(huì)有不同。后來(lái)專門花了點(diǎn)功夫,才了解Windows平臺(tái)下的開發(fā)有多個(gè)不同的體系:標(biāo)準(zhǔn)C,Windows API,MFC,STL。這些都是預(yù)先編寫好的庫(kù),實(shí)際開發(fā)時(shí)選哪個(gè),取決于項(xiàng)目的規(guī)模和性質(zhì)、程序的風(fēng)格,還有個(gè)人的喜好。

            一、自由世界中的C\C++

            1. CRT

            運(yùn)行時(shí)庫(kù)就是C Run-Time Library,是C而非C++語(yǔ)言世界的概念。取這個(gè)名字就是因?yàn)槟愕腃程序運(yùn)行時(shí)需要這些庫(kù)中的函數(shù)。

            C語(yǔ)言是所謂的“小內(nèi)核”語(yǔ)言,就其語(yǔ)言本身來(lái)說(shuō)很小(不多的關(guān)鍵字,程序流程控制,數(shù)據(jù)類型等);所以,C語(yǔ)言內(nèi)核開發(fā)出來(lái)之后, Dennis Ritchie 和 Brian Kernighan 就用C本身重寫了 90% 以上的 UNIX 系統(tǒng)函數(shù),并且把其中最常用的部分獨(dú)立出來(lái),形成頭文件和對(duì)應(yīng)的 LIBRARY,C run-time library 就是這樣形成的。

            隨后,隨著C語(yǔ)言的流行,各個(gè)C編譯器的生產(chǎn)商/個(gè)體/團(tuán)體都遵循老的傳統(tǒng),在不同平臺(tái)上都有相對(duì)應(yīng)的 Standard Library,但大部分實(shí)現(xiàn)都是與各個(gè)平臺(tái)有關(guān)的。由于各個(gè)C編譯器對(duì)C的支持和理解有很多分歧和微妙的差別,所以就有了ANSI C;ANSI C(主觀意圖上)詳細(xì)的規(guī)定了 C 語(yǔ)言各個(gè)要素的具體含義和編譯器實(shí)現(xiàn)要求,引進(jìn)了新的函數(shù)聲明方式,同時(shí)訂立了 Standard Library 的標(biāo)準(zhǔn)形式。所以C運(yùn)行時(shí)庫(kù)由編譯器生產(chǎn)商提供。至于由其他廠商/個(gè)人/團(tuán)體提供的頭文件和庫(kù)函數(shù),應(yīng)當(dāng)稱為第三方 C 運(yùn)行庫(kù)(Third party C run-time libraries)。

            C Run-Time Library里面含有初始化代碼,還有錯(cuò)誤處理代碼(例如divide by zero處理)。你寫的程序可以沒有 math庫(kù),程序照樣運(yùn)行,只是不能處理復(fù)雜的數(shù)學(xué)運(yùn)算,不過(guò)如果沒有了C Run-Time Library,main()就不會(huì)被調(diào)用,exit()也不能被響應(yīng)。因?yàn)镃 Run-Time Library包含了C程序運(yùn)行的最基本和最常用的函數(shù)。

            2. Standard C++ Library

            到了 C++ 世界里,有另外一個(gè)概念:Standard C++ Library,它包括了上面所說(shuō)的C Run-Time Library和STL。包含C Run-Time Library的原因很明顯,C++ 是 C 的超集,沒有理由再重新來(lái)一個(gè) C ++ run-time library。VC針對(duì)C++ 加入的Standard C++ Library主要包括:LIBCP.LIB, LIBCPMT.LIB和 MSVCPRT.LIB。

            二、Microsoft的C\C++

            1. Windows中的CRT

            CRT原先是指Microsoft開發(fā)的C Runtime Library,用于操作系統(tǒng)的開發(fā)及運(yùn)行。后來(lái)在此基礎(chǔ)上開發(fā)了C++ Runtime Library,所以現(xiàn)在CRT是指Microsoft開發(fā)的C/C++ Runtime Library。在VC的CRT/SRC目錄下,可以看到CRT的源碼,不僅有C的,也有C++的。

            CRT原先的目的就是支持操作系統(tǒng)的運(yùn)行。因?yàn)閃indows操作系統(tǒng)除匯編部分外,都是用C/C++編寫的,所以內(nèi)核及許多關(guān)鍵服務(wù)都在CRT上運(yùn)行(它們都采用dll技術(shù)動(dòng)態(tài)鏈接)。此外,用 VC編寫的C/C++程序也用到它們(可以動(dòng)態(tài)鏈接,也可以靜態(tài)鏈接,前者運(yùn)行時(shí)需要系統(tǒng)中已安裝CRT的dll,后者不需要)??梢哉f(shuō),CRT就是 Microsoft編寫Windows時(shí)使用的低層類庫(kù)。然后,它又被當(dāng)作C++標(biāo)準(zhǔn)庫(kù)的一個(gè)實(shí)現(xiàn)包含在了VC系列中;我們?cè)赩C中使用的C++標(biāo)準(zhǔn)庫(kù),其實(shí)就是CRT的一個(gè)真子集(少了C++標(biāo)準(zhǔn)所不包含的代碼,特別是大量的低層C代碼)

            C++標(biāo)準(zhǔn),是C++的通用語(yǔ)言規(guī)范,指導(dǎo)所有C ++使用者。而CRT的其中一部分可以看作是Microsoft開發(fā)的一個(gè)C++標(biāo)準(zhǔn)庫(kù)實(shí)現(xiàn)(其實(shí)也確實(shí)如此,Microsoft在開發(fā)CRT時(shí),參考了正在標(biāo)準(zhǔn)化過(guò)程中的C++語(yǔ)言規(guī)范)。它與C++標(biāo)準(zhǔn)有一定的差距,部分原因是,在C++沒有完成標(biāo)準(zhǔn)化之前,CRT已經(jīng)開發(fā)并投入使用了。為了向下兼容以前的Windows代碼,早期的CRT與C++標(biāo)準(zhǔn)總有一定的差距。但是CRT確實(shí)在不斷的改進(jìn)中。VC6帶的CRT與C++標(biāo)準(zhǔn)還有比較大的差距,而 VC8的幾乎完全符合C++標(biāo)準(zhǔn)了。

            2. Windows中的CRT與Windows API

            至于CRT與WINDOWS API的關(guān)系,與許多人理解的相反,WINDOWS API作為Windows的一部份,是在CRT的基礎(chǔ)上開發(fā)的。你可以將Windows(及其API)看作一個(gè)項(xiàng)目,而這個(gè)項(xiàng)目使用的語(yǔ)言是匯編/C/C ++,使用的類庫(kù)就是CRT。所以,離開CRT,Windows API也無(wú)法使用的。

            在編寫操作系統(tǒng)時(shí),你需要一個(gè)合適的低層庫(kù),以便完成一些基本的、多次重復(fù)的工作。于是,就有了CRT。在最低層的時(shí)候,根本連DLL這個(gè)概念都沒有的,所以CRT的源代碼只能做成lib,被靜態(tài)鏈接。然后,隨著Windows越做越復(fù)雜,Microsoft提出了API的概念,它提供Windows開發(fā)者一組接口,可以直接操作Windows,這就是Windows API了。當(dāng)然,Windows API也是在CRT之上編寫的。

            接著,Microsoft想給予C/C++程序員以足夠的支持,除了原始CRT之外,還要增加在Windows平臺(tái)上編程所特有的東西,如thread等等。這些東西都是和平臺(tái)相關(guān)的,只能建立在Windows API上。而這些新增內(nèi)容,也被放進(jìn)了CRT中。此時(shí),CRT不僅僅包含最低層平臺(tái)無(wú)關(guān)的代碼,還包括平臺(tái)相關(guān)的部分。如你調(diào)用CRT的 _beginthread,其實(shí)內(nèi)部調(diào)用了Windows API的CreateThread。加入這些東西后,CRT仍然被用作編寫操作系統(tǒng);但是顯然,那些調(diào)用了Windows API的部分已經(jīng)失去移值性了。

            然后,CRT被封裝成產(chǎn)品,隨編譯器一起發(fā)布。此時(shí)CRT產(chǎn)品的LIB和DLL都是Windows格式的,你不能在Windows以外的平臺(tái)上使用EXE或DLL吧,這就是CRT和CRT產(chǎn)品的區(qū)別。Windows API的產(chǎn)品,或是Windows的其他許多組成部分也是一些LIB/DLL文件,這些都是表面的東西,是與Windows綁定在一起的。但是,如果你認(rèn)為是先有Windows或Windows API,才有CRT的,那你就本末倒置了。除非你對(duì)CRT的定義就是那些LIB/DLL產(chǎn)品,而不包括用來(lái)產(chǎn)生它們的代碼。

            當(dāng)然,CRT的一些組成部分也調(diào)用了Windows API。這可能就是有人認(rèn)為CRT是建立的Windows API基礎(chǔ)上的原因。但是實(shí)際上,這一部分剝離CRT沒有任何的問(wèn)題。只不過(guò)Microsoft將在Windows平臺(tái)上可以使用的C/C++低層庫(kù)都加入到CRT中。因此,CRT中很大一部分是操作系統(tǒng)平臺(tái)無(wú)關(guān)的(原始的CRT),是開發(fā)Windows本身及其上一切的基礎(chǔ)。它們也可以作為一個(gè)C/C+ +庫(kù)在其他操作系統(tǒng)平臺(tái)上使用。還有一部分,則是和Windows緊密綁定的,調(diào)用Windows API來(lái)實(shí)現(xiàn)的,可以看作擴(kuò)展的CRT。之所以將這兩部分放在一起,是因?yàn)樗鼈兌际情_發(fā)Windows操作系統(tǒng)所需要的,也因?yàn)樗鼈円捕际荳indows 平臺(tái)上的C/C++程序員所需要的。這種復(fù)雜關(guān)系是Microsoft的人為因素造成的,不能因此認(rèn)為CRT是建立在Windows或Windows API基礎(chǔ)上的。

            綜上,CRT(Microsoft's C/C++ Runtime Library)的一個(gè)真子集(主要是C++ Runtime Library)是一個(gè)符合(或至少是企圖符合)C++標(biāo)準(zhǔn)的C++庫(kù)。而Windows API(以及Windows的其他許多部分)都是在CRT的基礎(chǔ)上開發(fā)的。

            最后再說(shuō)一句,C++當(dāng)然不是Microsoft的專利。但是Microsoft選擇了C++,并取得了成功,這是肯定的了:象CRT,象VC,象Windows,象Office,象 SQL Server等等。這一方面說(shuō)明了C++的優(yōu)勢(shì),一方面也是Microsoft自身的因素在起作用。然后,它當(dāng)然要緊抓C++的大旗,大力宣揚(yáng)它自己的C++,并排斥其他的C++。這就是帝國(guó)的“風(fēng)范”了。所以對(duì)Microsoft,總是即恨且愛,總希望哪天它會(huì)良心發(fā)現(xiàn)——當(dāng)然這只是幻想罷了。不過(guò),肯定該肯定的,否定該否定的,總是應(yīng)該的。但就產(chǎn)品而言,Microsoft不是最好的,但大多都是最成功的,在看到它的不足的同時(shí),也要看到它的優(yōu)點(diǎn)。存在的即使不是合理的,也一定有它的合理性。所以,不能簡(jiǎn)單用一兩句話評(píng)價(jià)Microsoft及它的成功。惟有一點(diǎn)是可以肯定的,它決定選擇C ++,真是太英明了!

            原帖連接:

            http://leowzj1985.spaces.live.com/blog/cns!5552BF8B7C951399!306.entry

             

            本文來(lái)自CSDN博客,轉(zhuǎn)載請(qǐng)標(biāo)明出處:http://blog.csdn.net/MoonAndWind/archive/2009/07/03/4320022.aspx

            posted on 2009-08-11 15:29 pear_li 閱讀(895) 評(píng)論(0)  編輯 收藏 引用

            亚洲国产小视频精品久久久三级 | 久久性生大片免费观看性| 色综合久久综精品| 久久综合狠狠综合久久激情 | 久久国产亚洲精品无码| 1000部精品久久久久久久久| 婷婷综合久久狠狠色99h| 久久久久综合国产欧美一区二区 | 色狠狠久久综合网| 99久久99久久精品免费看蜜桃| 久久精品无码专区免费| 亚洲色大成网站www久久九| 一本一道久久精品综合| 亚洲精品无码久久久久去q | 天天爽天天狠久久久综合麻豆| 97久久精品午夜一区二区| 亚洲性久久久影院| 亚洲精品高清国产一久久| 无码人妻久久一区二区三区免费丨 | 日韩人妻无码精品久久久不卡| 伊人久久免费视频| 国产麻豆精品久久一二三| 中文字幕无码久久精品青草| 国产高潮国产高潮久久久91| 久久久免费精品re6| 一本久久a久久精品vr综合| 久久毛片一区二区| 亚洲人成无码久久电影网站| 成人国内精品久久久久影院| 久久精品国产2020| 狠狠色丁香婷婷久久综合| 午夜精品久久影院蜜桃| 欧美久久一级内射wwwwww.| 久久99精品免费一区二区| 国产精品免费久久久久久久久 | 色婷婷综合久久久中文字幕| 久久天天躁狠狠躁夜夜躁2014| 欧美午夜精品久久久久久浪潮| 岛国搬运www久久| 久久久久久毛片免费看| 久久久无码精品午夜|