C++還能重新輝煌嗎？C++復(fù)雜性的思考

2019-11-17 05:25:46

字體：大中小

供稿：網(wǎng)友

　　C++的表面困境來自兩方面，一是開發(fā)效率低，而是輕易犯錯，維護難度大。此二者俱是表象，本質(zhì)就是一個——過度復(fù)雜?；蛴腥苏fC++之要害缺陷是沒有統(tǒng)一完整的類庫支撐，Bjarne Stroustrup即強調(diào)此因素。然而這其實只不過是一個結(jié)果，而不是原因。正是因為語言太復(fù)雜，才無法在有效期內(nèi)開發(fā)出高質(zhì)量的大一統(tǒng)的類庫。

　　C++的復(fù)雜，并非是其體積龐大之必然結(jié)果。復(fù)雜是對結(jié)構(gòu)混亂無序程度的描述，規(guī)模大，結(jié)構(gòu)不見得必然復(fù)雜。

　　C++的復(fù)雜，也并不是如很多人所認為，是若干種編程范式（paradigms）的并存而至。事實上，現(xiàn)代實用編程語言至少有2-3種范式才能登大雅之堂。以范式數(shù)量論，Python和Ruby等新型動態(tài)語言的范式甚至多于C++，然而它們卻以簡單和開發(fā)效率高著稱。

　　C++復(fù)雜的根源在于三大約束：與C的完全兼容、靜態(tài)類型檢查、最高性能。在三大約束下，C++未能完善對于面向?qū)ο笏枷氲闹С?，未能建立強大的動態(tài)能力，從而使得C++在OO這個單項上存在本質(zhì)缺陷。事實上，C++的過程、OB模型相當成熟和穩(wěn)定，而泛型模型，就單項來說，除了語法丑陋之外也沒有大的問題。缺陷集中體現(xiàn)在OO模型的實現(xiàn)，并因此干擾了其他幾個范式的完整程度。然而，OO的缺陷絕非設(shè)計者的偏執(zhí)，其原因在于三大約束。假如堅持三大約束，則即使再重新設(shè)計一次，結(jié)果也與今日相差不遠。Stroustrup在多種場合表示，對C++的設(shè)計沒有大的后悔之處，意思就是這個。侯捷先生早在2001年初即對我說，C++在OO上不及java，當時體會不深，認為沒有大一統(tǒng)的單根類庫會使設(shè)計更加靈活，后來又認為憑借GP可以抵消OO的不足甚至超越之，現(xiàn)在看來即使不是不可能，這條道路也必然是艱辛異常，成敗難以預(yù)料。

　　又因為上述所有因素的綜合作用，C++基礎(chǔ)類庫的建設(shè)只能進行到很低的高度上就停下來，因為再往上走就面臨重重困境和無窮無盡的爭論。C++標準庫實際上是一個距離應(yīng)用相當遙遠的非常基礎(chǔ)的程序庫，其主體部分只相當于Java中System和Util兩個package。而C++寧可停在這樣的低層次，也不愿意放棄三大約束中的任何一個。這種執(zhí)著使得高層標準庫設(shè)施的建立異常困難，使用也不輕易。Boost庫中相當部分組件的易用性不佳。

　　模板的復(fù)雜語法與三大約束也有直接的關(guān)系。另一個原因是Bjarne在發(fā)明模板時目標單純。C#和Java加入泛型機制的時候，沒有繼續(xù)C++最好的經(jīng)驗，卻不約而同地繼續(xù)了C++模板機制中最壞的部分——語法，短期來看，喪失了一次改革的良機。長遠來看，必成累贅。

　　不完善的異常機制則是在木已成舟的情況下迫不得已的設(shè)計。

　　C++中的多種范式并行，是一些最復(fù)雜問題的表面原因。以至于Doug Lea建議在一個項目里只堅持一個范式。但是這仍然只是表象。歸根結(jié)底還是因為OO的缺陷，使得與其它范式合作時困難成倍放大。故自接受Doug Lea思想以來，我的C++（乃至其他現(xiàn)代語言，尤其是Python等多范式語言）的開發(fā)設(shè)計思路是：

　　1. 首先選定一種思維方式（即范式），盡可能只用這一種思維方式解決問題；

　　2. 假如在局部碰到其他思維方式更得力的問題，則經(jīng)慎重考慮后，可以將另一種風(fēng)格包裝在局部，解決局部問題。但整個系統(tǒng)在某一層次之上看來，應(yīng)當是統(tǒng)一一致的。一般C++的開發(fā)，應(yīng)以O(shè)B為基本風(fēng)格。除非有類似MFC那樣龐大而成熟的OO庫支持，不應(yīng)貿(mào)然在整體上使用OO風(fēng)格。

　　3. 多種風(fēng)格混用，除非有已被充分討論并驗證的方案（即成熟模式），可提供單一風(fēng)格不能提供的較大優(yōu)勢，否則應(yīng)極力避免。當然鼓勵在研究中探索，但實踐是另一回事。

　　C++完全可以在90年左右擺脫C的約束，隨后簡化模板語法，完善異常模型，接納可選GC，建立完整的單根類庫，付出性能小幅度下降的代價之后，實現(xiàn)語言整體升級。

　　但是C++選擇了另一條路，三大約束堅持到底，堅守系統(tǒng)層面，以替代C為己任。是福是禍，實難判別。假如90年代初選擇升級，勝則扼死Java于搖籃之中，敗則寸土不保。不過以C++之高性能，勝面應(yīng)稍大。如今看來，在系統(tǒng)面徹底取代C已無可能。

　　1994年為STL拖延標準立案時間長達四年，如今來看功過亦存爭議。錯過黃金時機不說，STL典范一立，庫設(shè)計風(fēng)氣為之一改。然而在解決應(yīng)用問題上，泛型較之OO，適應(yīng)能力遠遜之，且應(yīng)用困難。

　　總之，C++的三大約束，既是其興起之要素，也是其衰落之源頭，同時，又是其今天得以屹立不倒的重要基石。其是非功過，實難一言以蔽之。

　　C++/CLI之對于C++的意義，其實并不在于使C++重新獲得了制勝Java或者C#的機會，而在于鞏固了C++作為.NET平臺上系統(tǒng)語言的地位。由此知，C++/CLI的發(fā)展，的確如Stan Lippman所說，是C++一貫發(fā)展思路的延續(xù)。三大約束固然已經(jīng)放棄，但其精神實質(zhì)仍在，形攻而實守，未來將可作為.NET上唯一最強之系統(tǒng)語言而長命百歲。

　　C++/CLI決不簡單，但在大多數(shù)時候，它能夠比傳統(tǒng)的C++表現(xiàn)的簡單些。這就是Andrew Koenig說的，通過復(fù)雜實現(xiàn)簡單。

　　C#和Java的繁榮期，則有賴于人們對于大一統(tǒng)的中層次語言的信仰有多堅持。此兩種語言無論在系統(tǒng)開發(fā)還是在應(yīng)用開發(fā)中都非最優(yōu)選。目前C#出現(xiàn)一些跡象，引入一些動態(tài)語言特性如cmdlet，又強化系統(tǒng)編程能力，想上下通吃。這是一條不歸路，必會使C#變得更加復(fù)雜怪異。

　　學(xué)習(xí)編程語言，通語法能實踐，不過十分之一。真正重要的是把握其多種多樣的實用的idioms或模式。這些模式才是體現(xiàn)了語言精神的東西。未把握各種語言中的主要應(yīng)用模式，則應(yīng)羞于用“會”字。常聽有人說某某語言一周乃至一兩天即可把握，這個把握的層次肯定是很低的。真正要“把握”語言，則我等凡人，諸事纏身，非得集中精力學(xué)習(xí)實踐一兩年，將該語言所擅長領(lǐng)域的應(yīng)用問題熟悉過一遍，才有可能。若論精通，則十年也不輕易。Henry Spencer用了30年C，仍樂此不疲；PRagmatic Programmer中評價Ruby說，學(xué)上四個小時就可以用它解決實際問題，但是10年之后還為它層出不窮的新意感到驚奇。偶見有人舉出自己“精通和把握”的工具和語言，動輒長達八九上十種，實為笑柄。真正把握一種，已經(jīng)是難能可貴，熟練把握兩種層次不同，思維不同的語言，應(yīng)是有抱負的程序員的自我要求。何況如今之軟件開發(fā)涉獵甚廣，僅通編程層次還顯不夠。不過總之百招會不如一招精，做什么工作都要有自己的過人之處。

上一篇：“Hello world!”的N種寫法

下一篇：對C++標準委員會強制For循環(huán)的不同看法