C99標準介紹(轉載)

本文轉自:http://tb.blog.csdn.net/TrackBack.aspx?PostId=795910

 

新的C語言: C99標準介紹

此篇文章摘取與即將登載於《Dr.Dobb's 軟件研發》》第二期(2003年9月)的《新的C語言,C99標準介紹》,文章主要是介紹了C99的新特性,在得到作者Randy Meyers以及《Dr.Dobb's 軟件研發》》負責人劉江先生的應允下,把全文的前面的一部分作爲文檔發表,希望能對大家有所幫助。

譯註2:C語言的產生源於失敗的項目---Multics。從70年代初期的早期C語言到後來的K&R C, ANSI C,C89,在將近20年中C語言多次發展演化,一直到1999年C語言又重新定案,成爲新的C語言標準。這篇文章發表在 CUJ Octorber 2000 V18 N10,當時C99標準剛剛公佈一年,C社區正急需正統的聲音。本文作者Randy Meyers作爲標準委員會委員,在CUJ雜誌開了一個專題系列The New C用來討論新標準的新特性,本文就是其中的第一篇。本文從全局上介紹了新標準C,尤其是一些增加的特性,期望本文能給關心C語言和使用C語言的用戶帶來幫助。在翻譯上,所有譯者在翻譯過程中有疑惑的術語或者其他一切都以括號形式把原文直接給出,誠心不想給讀者半點誤導,但是否如願還需讀者的評判,關於本文的一切可以用[email protected]與譯者聯繫和討論。

C99很像C89,很多地方是一致的,但更多的卻是不同。

簡介

你可能沒有注意到,針對ANSI/ISO   C的主要的修訂版[1] 在去年12月已經被覈准通過,那是就C99。同樣的,你可能也沒注意到,其實你已經在使用這個新的C語言了,或者至少用到它的一部分。這需要歸功於標準委員會在接受新特性到C語言的過程中採取了恰當而保守的方式。差不多所有的新特性早已經被實現並且在現存的一些C編譯器(impletmentations)中證明了其存在的價值。雖然沒有編譯器能保證全部的C99特性,但其中許多在很多年前就實現了C99中不同的部分。這對於C程序員來說將是個好消息。或許你曾經爲了保證程序的可移植性而在你喜愛的編譯器裏避免使用一些獨立的特性,但現在如果這些特性是C99中的一部分的話,你可以放心的使用這些特性,因爲他們將在大部分遵守C99標準的編譯器中被保證。毫無疑問,新標準是向上兼容舊的,當然也會有些不兼容地方,但這些都是非常少而次要的。標準委員會非常努力地工作就是爲了將和老版本的兼容性問題所帶來的影響減少到最小。從後面討論到的關鍵字你可以看到這方面的例證。

命名和歷史

程序設計語言隨着時間在不斷演進,語言的命名方式不僅僅依賴於語言本身的名字,還結合了它們被定義的年代。(回到五年前,ALGOL 68, C89, Fortran 77還有Fortran 4,我對這些名字真的感到好笑,如今這些令人討厭的命名方式還帶來了千年蟲問題,04將無法區別眼前的2004或者久遠的1904)。新的C語言和定義它的新標準被稱爲C99,而原來的C語言標準[2]被稱爲C89或者C90(ANSI在1989年公佈了標準文檔而ISO在1990年重新編排了標準文檔章節後才公佈)。如果你在自己的程序中處理過日語,韓語,或者中文的文字問題你也許會知道對於C89來說曾經有一次小的升級[3]被稱爲C95,這次升級主要是加入了更多的用來處理多字節和寬字節字符(wide and multibyte characters)的庫函數(Java的倡導者曾經錯誤的宣佈Java是第一個支持大字符集合的語言,其實這樣的支持在C89中就已經存在了)。

對於C99施加影響最大的或許就是數值C語言擴展小組(Numerical C Extensions Group, or NCEG.)。NCEG是ANSI C標準委員會J11的一個子委員會,他們主要在C89完成後從事技術報告工作[4]。NCEG的技術報告不是標準,它只是號召編譯器實現者來體會並且得到那些一系列描敘清楚的語言特性的經驗。這些擴展中大的部分是用來處理C語言數值編程的(IEEE arithmetic, complex numbers),但是還有一些是爲了其他一般目標或者性能的提升和優化(變長數組,並行處理,restrict關鍵字)。

NCEG的擴展一些是由子標準委員會首次定義的,而其他一些則是根據編譯器廠商對於已經實現的特性的反饋而重新定義的。所以技術報告不是標準,編譯器廠商可以自由的選取並且實現這些擴展,甚至可以根據用戶的經驗更改這些擴展。

真實世界的需求是非常有價值的。語言的不同特性在內部會以一種令人喫驚的方式相互作用,而有的特性將會給程序的運行效率帶來不良影響,即使這些特性永遠都不會被用到(舉例來說,在一些C++的實現中,使用少量多繼承的程序將會比只使用單繼承的程序慢一些)。NCEG的擴展實驗不僅僅是爲了改進擴展本身,同時是爲了改進它們的規格,並且讓標準委員會對於那些已知的語言特性的內部作用和價值保持信心。

哪些不屬於C99

並不是所有的NCEG擴展都被C99所接受,其中最大的例子也許就是NCEG對並行處理的支持並沒有被C99所接受。這些並行處理是基於 Thinking Machines上的C*語言(讀作C-Star)的。並行計算機制造商爲了能讓程序員寫出清晰的並行程序代碼而做出許多不同的擴展特性,而NCEG技術報告對此卻沒有做出改進,所以仍然沒有一致的並且是最好的方式在並行計算機上編程。因此,這樣的特性是不適合被標準C語言接受的。另外一些NCEG擴展在被加入到C99之前做了一些更改。NCEG支持的複數包含分開的虛數數據類型(separate imaginary datatypes)。比如,double_ imaginary數據類型。但是在C99中虛數數據類型卻是可選擇的。

然而,被考慮得最多到最後卻沒有被C99採納的特性不是來自NCEG,而是C++。在將近一年的時間裏,標準委員會一直在從事C ++中的子集--面向對象特性的研究工作。這個子集有點像80年代末的C++特性的混合,包括單繼承(非多繼承),虛函數,成員訪問控制(公有,私有,保護),構造函數,析構函數。如果新的C語言與早期的C++相似可以說是既有進步也有退步。積極的一面是,這些特性對於初期C++的流行起到了巨大作用,到現在這些特性的價值和它們之間的內在作用已經被大家很好的理解,而且已經證明它們是可以共存的。然而,消極的一面是“90年代的C++是否可以看作是80 年代的C++的自然演化?如果是, C採用80年代的C++的特性價值何在?要知道我們已經擁有90年代的C++了。”最終,多方面的原因,包括一些邏輯上的,讓標準委員會拒絕把面向對象特性加入到C語言中去。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章