C++当年从应用开发的王座上跌落，不是因为它有模板，而是因为它缺少更强的动态能力。基本上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是符合我的美学观——简单而又强大，这一点跟云风意见一致。