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