本文詳細介紹說明C++編程語言中的多種范式并行，是一些最復雜問題的表面原因。以至于Doug Lea建議在一個項目里只堅持一個范式。但是這仍然只是表象。歸根結底還是因為OO的缺陷，使得與其它范式合作時困難成倍放大。

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

2. 如果在局部遇到其他思維方式更得力的問題，則經慎重考慮后，可以將另一種風格包裝在局部，解決局部問題。但整個系統在某一層次之上看來，應當是統一一致的。一般C++的開發，應以OB為基本風格。除非有類似MFC那樣龐大而成熟的OO庫支持，不應貿然在整體上使用OO風格。

3. 多種風格混用，除非有已被充分討論并驗證的方案（即成熟模式），可提供單一風格不能提供的較大優勢，否則應極力避免。當然鼓勵在研究中探索，但實踐是另一回事。C++完全可以在90年左右擺脫C的約束，隨后簡化模板語法，完善異常模型，接納可選GC，建立完整的單根類庫，付出性能小幅度下降的代價之后，實現語言整體升級。

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

1994年為STL拖延標準立案時間長達四年，如今來看功過亦存爭議。錯過黃金時機不說，STL典范一立，庫設計風氣為之一改。然而在解決應用問題上，泛型較之OO，適應能力遠遜之，且應用困難。總之，C++的三大約束，既是其興起之要素，也是其衰落之源頭，同時，又是其今天得以屹立不倒的重要基石。其是非功過，實難一言以蔽之。

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

C++/CLI決不簡單，但在大多數時候，它能夠比傳統的C++表現的簡單些。這就是Andrew Koenig說的，通過復雜實現簡單。

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

學習編程語言，通語法能實踐，不過十分之一。真正重要的是掌握其多種多樣的實用的idioms或模式。這些模式才是體現了語言精神的東西。未掌握各種語言中的主要應用模式，則應羞于用“會”字。常聽有人說某某語言一周乃至一兩天即可掌握，這個掌握的層次肯定是很低的。

真正要“掌握”語言，則我等凡人，諸事纏身，非得集中精力學習實踐一兩年，將該語言所擅長領域的應用問題熟悉過一遍，才有可能。若論精通，則十年也不容易。Henry Spencer用了30年C++編程語言，仍樂此不疲；Pragmatic Programmer中評價Ruby說。

學上四個小時就可以用它解決實際問題，但是10年之后還為它層出不窮的新意感到驚訝。偶見有人舉出自己“精通和掌握”的工具和語言，動輒長達八九上十種，實為笑柄。真正掌握一種，已經是難能可貴。

熟練掌握兩種層次不同，思維不同的語言，應是有抱負的程序員的自我要求。何況如今之軟件開發涉獵甚廣，僅通編程層次還顯不夠。不過總之百招會不如一招精，做什么工作都要有自己的過人之處。