C++當年從應(yīng)用開發(fā)的王座上跌落，不是因為它有模板，而是因為它缺少更強的動態(tài)能力。基本上C++就是一種靜態(tài)語言，其所謂動態(tài)性都是就編譯時而言的。一旦編譯完成就成為鐵板一塊。這個問題在單機時代還可以將就，到了網(wǎng)絡(luò)時代就是不可容忍的問題。因此，按照毛主席的矛盾論思想說，實際上C++在90年代中期面臨的主要矛盾是落后的靜態(tài)執(zhí)行模型與應(yīng)用程序動態(tài)化之間的矛盾。但是C++當時并沒有著力解決這個矛盾（到現(xiàn)在連個統(tǒng)一的ABI都沒有），反而在次要矛盾（開發(fā)效率）上下功夫，花了極大的精力去完善模板設(shè)施。再加上其他固有的問題（GC, debug, pointer, 復(fù)雜性），C++就從王座上跌下來了。
這也可以解釋，為什么Windows/MFC/COM仍然是目前C++應(yīng)用的單一最大場合——因為COM是微軟為C++提供的一個動態(tài)運行環(huán)境。遺憾的是，COM設(shè)計得太復(fù)雜，而且犯了一些錯誤（讀讀這篇文章http://www.relisoft.com/win32/olerant.html），所以跟后來的那些什么Java、.NET相比就相形見絀了。
總之，C++仍然是目前制造單塊系統(tǒng)最好的語言（效率高，抽象機制豐富，可移植性好），但用于構(gòu)造整個應(yīng)用，特別是網(wǎng)絡(luò)應(yīng)用，就很不合適了，至少是不經(jīng)濟。
因此，C++未來的位置只能是不斷完善自己作為系統(tǒng)級部件語言的位置。從這個角度看：
1. Ice：用C++開發(fā)了完整的網(wǎng)絡(luò)中間件，解決了動態(tài)性問題，并且可以跨語言。這是我認為3年以來C++開發(fā)中最令人激動的項目。
2. 陳榕的Elastos：陳榕對于這個問題的認識是很深刻的。幾年以前他給我講得其實就是這個道理，只不過我最近才想明白。他認為在構(gòu)造單個部件方面，C++由于C#、VB、Java，特別是在嵌入式平臺上優(yōu)勢明顯。而主要的缺陷是C++部件的動態(tài)性能極度匱乏，這里的關(guān)鍵因素又是因為C++部件中的metadata匱乏。因此陳榕給C++部件添加完整的metadata，并開發(fā)運行時來支持。陳榕的思想實際上與Ice是一致的，只不過兩者一個是從CORBA出來的，一個是從COM出來的，殊途同歸而已。我非常認同陳榕的發(fā)展方向，唯一的擔憂是，陳榕的C++部件metadata是與.NET兼容的，而目前企業(yè)應(yīng)用中的主流是Java。這個矛盾應(yīng)該得到解決。如果陳榕的Elastos能夠同時兼容Java的metadata和.NET的metadata，我相信他會取得成功。
3. 微軟的C++/CLI，這個東西被罵得很慘，其實放在大背景下考慮，它是有意義的。實際上它的出現(xiàn)是同樣基于我上面提到的一個觀點，即做零件的話，你們誰也不如C++。所以C++是有優(yōu)勢的，只不過要把C++作出來的零件跟其他的零件自如拼裝。C++/CLI致力于在.NET體系內(nèi)部解決這個問題，不能說這個想法是不對的，我認為這個技術(shù)將會得到一定程度的應(yīng)用。
4. 相比之下，像ACE/MFC/Qt這類大型的框架，雖然已經(jīng)非常成熟，但是未來將局限在一個比較小的領(lǐng)域里，局面會比較尷尬。因為它們是用來開發(fā)整個應(yīng)用程序的，而未來大家不太會用C++來開發(fā)整個應(yīng)用。那么用它們來開發(fā)部件如何呢？不好，因為它們開發(fā)出來的部件不能與外界交互。不過ACE還是有一定空間的，因為它的可移植性超好，可以往嵌入時平臺上擠，而且在上面還有TAO和CIAO。
5. ATL怎樣呢？那完全取決于COM的命運。只要COM在Windows中還處于核心的地位，ATL就還是很重要的技術(shù)。
6. Boost對于C++來說，只是一個補充性質(zhì)的事件，無關(guān)乎大局。
7. 我一直堅信未來會出現(xiàn)高低搭配的局面，像Java/C#這樣的半動不靜的中級語言會逐漸“淪為”JVM和CLR上的系統(tǒng)語言，應(yīng)用開發(fā)的任務(wù)必將由更加動態(tài)的腳本語言承擔。目前的Python, Ruby和Lua都有可能。如果從我的角度講，我希望最后勝出的是Lua，因為Python思維有些混亂，Ruby雖然很純，但是語言設(shè)計過于復(fù)雜，只有Lua是符合我的美學(xué)觀——簡單而又強大，這一點跟云風意見一致。