C++:民主的產物

民主政體:C++的設計哲學

摘自《C++語言的設計與演化》

1) 這就意味着語言的設計已經脫離了“純粹的”和更抽象的學科,例如數學與哲學。爲了更好地爲了它的用戶服務,一種通用程序設計語言必須是折衷主義,需要考慮到很多實踐性和社會性的因素。

2) 特別地,每種語言的設計都是爲了解決一個特定問題集合的爲題,在某個特定時期,依據某個特定人羣對問題的理解。由此產生了初始的設計。而後它逐漸成長,去滿足新的要求,反映對問題以及對解決他們工具和技術的新理解。

3) 我矢志不渝的信念是:所有成功的語言都是逐漸成長起來的,而不是僅根據某個第一原則設計出來的。原則是第一個設計的基礎,也指導着語言的進一步演化,但是原則本身也是同樣是發展的。

4) 尊重人羣而不尊重人羣中的個體實際上就是什麼也不尊重。C++的許多設計決策根源於我對強迫人按某種特定方式行事的做法極度厭惡。歷史上一些最壞的災難起因就是理想主義者們試圖強迫人們“做某些對他們最好的事情”。這種理想主義不僅導致了對無辜者的傷害,也迷惑和腐化了施展權利的理想主義者的自身。我還發現,對於其教義或者理論出現不尋常的衝突的經驗和實驗,理想主義者往往有忽略它們的傾向。在理想出現問題的地方,甚至空談家也要贊成的時候,我寧願提供一些支持,給程序員以選擇的權利。

5) 經常遇到這種情況,如果我試圖去取締一個我個人不喜歡的語言特徵時,我總抑制住自己這樣做的慾望,因爲我不認爲自己有權把個人的觀點強加給別人。我知道通過強力地推行邏輯,毫無同情心地譴責“思想中壞的,過時的,混亂的習慣”,可能在相對短的時間裏有更多的建樹。但是,人的代價總是最高的。不同的人們確實會按不同的方式思考,喜歡按不同的方式做事情,對於這些情況的高度容忍和接受是我最願意的事情。

6) 我設計C++只是爲了解決一個問題,而不是想證明一種觀點,而它的成長有能夠服務於它的使用者。

7) 尤其是我絕不想通過一種很有侷限性的程序設計語言定義去推廣某種唯一的設計理念。人的思維方式是如此的豐富多彩,企圖推行一種唯一理念總是弊大於利的。這樣,C++被有意設計成支持各種各樣的風格,而不是強調“一條真理之路”。

8) 我的牢固信念是,語言設計並不是純粹的思維訓練,而是一種在需要,想法,技術,和約束條件之間取得平衡的非常實際的修煉。一個好語言不是設計出來的,而是成長起來的。這種修煉與工程,社會學和哲學的關係比數學的關係更密切些。

9) 對語言設計者總存在極大的誘惑,引誘他去提供某些特徵或者服務,而在這些地方,用戶原來需要採用迂迴的方式去解決問題。而且,要求添加某些要求被拒絕而產生的尖叫聲,遠比對“又增加了另一個無用特徵”的抱怨聲響亮得多。這種爭論的最壞變形就是對正交性的崇拜。許多人認爲,如果在語言中增加了一個特徵可以使他更具有正交性,那麼這就是接納這個特性的充分證據。我贊成正交性在原則上是一個好東西,但也注意到總要爲它付出代價。

10) 在正交性的所有好的含義之外,在手冊和指導材料中定義各種特徵的組合通常也需要做許多額外工作。

11) 對於C++,我總是考慮對那些不使用組合方式的人,正交性將在運行時間和空間付出什麼樣的代價。如果這種代價無法在原則上能成零,我就很不情願接受這個特徵——即使它是正交的。也就是說,正交性應該作爲第二位的原則——放在對於有用性和效率的最基本考慮之後。

12) 從根本上說,靜態類型檢查的概念被看成是爲了程序提供一種儘可能強的保證,而不僅僅被作爲一種取得運行效率的手段。

13) 很自然,靜態類型檢查對於調試很有幫助。但是把基礎放在靜態類型檢查上的最根本原因,則是我那時就確信(現在依然如此),一個由通過了靜態檢查的部件組合而成的程序與一個基於弱類型檢查或動態類型檢查的接口的程序比起來,更可能是忠實地表達了一種經過深思熟慮的設計。當然,也應該記住,並不是對每個接口都能徹底地做靜態類型檢查,靜態類型檢查也絕不意味着不會有錯誤。

14) 設計一個庫比增加一個語言特徵更好,這種情況是經常出現的。

15) 因爲沒有任何語言能支持人們所需要的全部特徵,又因爲即使語言的擴充被接受了,也還是需要時間去實現和部署,人們應該總把庫作爲第一選擇。設計一個庫,實際上經常能成爲追求新機制的狂熱的一種最具有建設性的發泄方式。只有在邁向庫的道路真正走不通的情況下,才應該踏上語言的擴充之路。

16) C++最有實力的地方並不是它的某個獨到之處特別偉大,而在於它在事物的大範圍變化中表現都很不錯。與此類似,從根本上說,其發展也不是來自某個孤立的進步,而是來自在不同領域的大量的各種各樣的進步。

17) 所有的語言都要死亡,或者爲迎接新的挑戰而改變。一個有着極大的而又活躍的用戶社團的語言將總是去改變而不是死亡。這就是發生在C語言上的事情,並因此產生了C++。到某一天,這種情況也可能出現在C++身上。

18) C++並不完美,它也沒有想成爲完美的東西,任何其他通用語言都不可能。但無論如何C++已經足夠好了,因此不會被另一個類似的語言所取代。只有某個根本上不同的語言纔有可能提供顯著而充分的優點,成爲明顯的更強者。

19) 僅僅作爲一個更好的C++還不足以導致一個大轉變,這就是爲什麼C++不能只是一個更好的C的原因:如果C++沒有提供重要的新的寫程序的方式,程序員就根本不值得從C方面轉過來。這也是爲什麼Pascal和Modula-2無法成爲C的替代性選擇的原因,雖然學術界中很重要的一部分人多年來一直推動這些語言也不能成功,因爲它們與C並沒有重要差別,其優點不那麼顯著。

20) 還有,如果某個更好但又沒有截然差別的東西出現,一個熱愛着原有事物的多樣化社會就會簡單地吸收那些新的思想和特徵。在C++的初始設計,以及它發展到當前這個語言的演化過程中,存在着許多這方面的例子。

21)C++長處,更多的在於它對許多問題都是很好的解決途徑,而不在於它對某個特定問題是最好的解決途徑。

C++的設計規則

規則與原理:

1)要成爲真正有用的,人們樂於使用的東西,程序設計語言的設計就必須有一種全局觀,用它來指導語言中各種特徵的設計。對於C++,這種全局觀有一組規則和約束構成。稱它們爲規則,是因爲我認爲原理這個詞在真正的科學原理非常貧乏的領域顯得過於自命不凡,而程序語言設計就是這樣的一個領域。

2)此外術語“原理”也意味着:任何例外都是不可接受的。而我的有關C++設計的規則幾乎可以保證都有例外的情況。實際上,如果一條規則與某個實際試驗發生衝突,這個規則就應該靠面站。這樣說,看起來似乎有些粗魯,但是它不過是一條一般性原則的變形:理論必須與試驗數據相吻合,否則就應被更好的理論取代。

C++的目標:

C++應該使認真的程序員能夠覺得編程序變得更愉快了。C++是一種通用的程序設計語言,它應該是:

1)一種更好的C

2)支持數據抽象

3)支持面向對象的程序設計

 

一般性規則:

最一般和最重要的C++規則與語言的技術方面並沒有太大的關係。這些規則幾乎都是社會性的,其關注點是C++所服務的社團。C++語言的性質很大程度上出於我的選擇,我認爲它們應該服務於當前的這一代系統程序員,支持他們在當前的計算機系統上解決當前遇到的問題。最重要的是,當前這個詞的意義和性質總是隨着時間而變化,C++必須能夠發展,以滿足它的用戶的需要;它的定義不應該是以成本不變的。

1) C++的發展必須由實際問題推動;

改變C++的正確推動力,是一些互相獨立的程序員證明了這個語言對於表述它們的工作項目存在哪些不充分的地方。我更喜歡來自非研究性的項目,無論何時,只要可能,在努力發現問題和尋找解決辦法時,我總設法與實際用戶聯繫。我如飢似渴地閱讀程序設計語言的文獻,尋找對於這些問題的解答,也尋找各種可能有所幫助的技術。但我也發現,文獻在考慮什麼是真正問題方面是完全不可靠的,理論本身並不能爲加入或者去掉一個特徵提供充分的證據。

2) 不被牽扯到無益的對完美的追求之中;

任何程序設計語言都是不是完美的。由於問題和系統都在持續的變化之中,將來也不可能有完美的語言。用許多年工夫去修飾一個語言,以圖去接近某種完美的概念,這樣做只能是使程序員無法從那些年的進步中獲益,也會使語言的設計者不能得到真實的反饋。沒有適當的反饋,一個語言就會逐漸發展成爲一種與時代不相關的東西。

重要改進的需求必須依靠反饋信息,並伴以對兼容性,轉變過程和教育的認真考慮。隨着語言的逐漸成熟,必須更多的傾向於使用基於工具,技術和庫的替代性方式,而不是去改變語言本身。

3) C++必須現在就是有用的;

4) 每個特徵必須存在一種合理的明顯的實現方式;

當然,使用者總比寫編譯器的人多得多,所以如果出現需要在編譯複雜性和使用複雜性之間的權衡問題,解決方案必定是偏向用戶的。我在許多年做編譯器維護的生涯中,已經真正理解了這個觀點。

5) 總提供一種轉變的通路;

要清除一種不安全,容易出錯或者簡單的有毛病的語言特徵,最一般的策略就是首選提供一種更好的替代品,然後建議人們避免使用老的特徵和技術,而到數年之後——如果要做的話 -再刪除那個有問題的特徵。這種策略可以有效的通過讓編譯器產生編譯警告信息方式去支持。

6) C++是一門語言,而不是一個完整的系統;

7) 爲每種應該支持的風格提供全面的支持;

簡潔是最基本的東西,但是這個問題也應該針對將要使用C++項目的複雜性來考慮。與保持語言的定義比較簡短相比,應該把用C++寫出的系統的可維護性和運行時的性能做爲更重要的問題。這實際上意味着要做一個相對規模較大的語言。

8) 不試圖去強迫人做什麼;

我也很清楚的意識到,並不是每個人都讚賞選擇和變化。無論如何,那些偏愛帶有較多限制環境的人可以在C++中始終如一的堅持使用某些規則,後者另去選擇一種只給程序員提供很小的一組選擇的語言。

設計支持規則:

1)支持健全的設計概念

不可能有一種語言能支持所有的風格,而如果一個語言只支持某種定義狹隘的設計哲學,它也將因爲缺乏適應性而失敗;

2)爲程序的組織提供各種機制

3)直接說出你的意思

縮小這種(不同程序員的編寫程序)語義鴻溝的最基本的方法是使得語言更具有說明性。C++語言提供的每種機制都與使某種東西更具說明性有關。然後是爲了一致性檢查,檢測出愚蠢的錯誤或者改進所生成的代碼而開發的一些附加結構。

4)所有特徵都必須是能夠負擔的

5)允許一個有用的特性比防止各種錯誤的使用更重要

你可以在任何語言中寫出很壞的程序。真正重要的問題是儘可能減少偶然將某些特徵用錯的機會。

當然,一個系統程序設計語言不應該禁止程序員有意識地去打破系統的限制,所以設計的努力應該更多地放在提供一些機制,幫助人寫出好的程序方面,而不是禁止不可避免的壞程序方面。

6)支持從分別開發的部分出發進行軟件的組合

語言的技術性規則:

1) 不隱式地違反靜態類型系統;

只要有可能,總在編譯時進行檢查。只要有可能,那些在處理單獨編譯單位時只能提供信息而無法檢查的東西,都有要在連接時進行檢查。最後,這裏還提供了運行時的類型信息和異常機制,以幫助程序員處理編譯和連接都無法捕獲到的錯誤條件。當然,在實踐中,還是編譯時的檢查代價更低,也更值得信賴。

2) 爲用戶定義類型,提供與內部類型同樣好的支持;

3) 局部化是個好事情

4) 避免對順序的依賴性

5) 如果有疑問,就選擇該特徵的最容易說清楚的形式

6) 語法是重要的(常以某些我們不希望的方式起作用)

保證類型系統的一致性,一般而言,保證語言的語義清晰,定義良好是最基本的東西。語法是第二位的,而且看起來人們能夠學會去喜愛任何語法形式。

7) 清除使用預處理程序的必要性

過去這些年,C++的最強和最弱的地方都在於它與C的兼容性。

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