本文系数月前随手写下的，没有起承转合与段落章法，观点更是未经推敲。仅供参考。
------------------------------------------------------------------------------------------
C++的表面困境来自两方面，一是开发效率低，而是容易犯错，维护难度大。此二者俱是表象，本质就是一个——过度复杂。或有人说C++之关键缺陷是没有统一完整的类库支撑，Bjarne Stroustrup即强调此因素。然而这其实只不过是一个结果，而不是原因。正是因为语言太复杂，才无法在有效期内开发出高质量的大一统的类库。
C++的复杂，并非是其体积庞大之必然结果。复杂是对结构混乱无序程度的描述，规模大，结构不见得必然复杂。
C++的复杂，也并不是如很多人所认为，是若干种编程范式（paradigms）的并存而致。事实上，现代实用编程语言至少有2-3种范式才能登大雅之堂。以数量轮，Python和Ruby等新型动态语言的范式甚至多于C++，然而它们却以简单和开发效率高著称。
C++复杂的根源在于三大约束：与C的完全兼容、静态类型检查、最高性能。在三大约束下，C++未能完善对于面向对象思想的支持，未能建立强大的动态能力，从而使得C++在OO这个单项上存在本质缺陷。又因为上述所有因素的综合作用，C++基础类库的建设只能进行到很低的高度上就停下来，因为再往上走就面临重重困境和无穷无尽的争论。C++标准库实际上是一个距离应用相当遥远的非常基础的程序库，其主体部分只相当于Java中System和Util两个package。而C++宁可停在这样的低层次，也不愿意放弃三大约束中的任何一个。这种执着使得高层标准库设施的建立异常困难，使用也不容易。Boost库中相当部分组件的易用性不佳。
模板的复杂语法与三大约束也有直接的关系。另一个原因是Bjarne在发明模板时目标单纯。C#和Java加入泛型机制的时候，没有继承C++最好的经验，却不约而同地继承了C++模板机制中最坏的部分——语法，短期来看，丧失了一次改革的良机。长远来看，必成累赘。
不完善的异常机制则是在木已成舟的情况下迫不得已的设计。
C++中的多种范式并行，是一些最复杂问题的表面原因。以至于Doug Lea建议在一个项目里只坚持一个范式。但是这仍然只是表象。归根结底还是因为OO的缺陷，使得与其它范式合作时困难成倍放大。
C++完全可以在90年左右摆脱C的约束，随后简化模板语法，完善异常模型，接纳可选GC，建立完整的单根类库，付出性能小幅度下降的代价之后，实现语言整体升级。
C++选择了另一条路，三大约束坚持到底，坚守系统层面，以替代C为己任。是福是祸，实难判别。如果90年代初选择升级，胜则扼死Java于摇篮之中，败则寸土不保。不过以C++之高性能，胜面应稍大。如今看来，在系统面彻底取代C已无可能。
1994年为STL拖延标准立案时间长达四年，如今来看功过亦存争议。错过黄金时机不说，STL典范一立，库设计风气为之一改。然而在解决应用问题上，泛型较之OO，适应能力远逊之，且应用困难。
总之，C++的三大约束，既是其兴起之要素，也是其衰落之源头，同时，又是其今天得以屹立不倒的重要基石。其是非功过，实难一言以蔽之。
补充：2004年10月20日
C++/CLI之对于C++的意义，其实并不在于使C++重新获得了制胜Java或者C#的机会，而在于巩固了C++作为.NET平台上系统语言的地位。由此知，C++/CLI的发展，的确如Stan Lippman所说，是C++一贯发展思路的延续。三大约束固然已经放弃，但其精神实质仍在，形攻而实守，未来将可作为.NET上唯一最强之系统语言而长命百岁。
C++/CLI决不简单，但在大多数时候，它能够比传统的C++表现的简单些。这就是Andrew Koenig说的，通过复杂实现简单。
C#和Java的繁荣期，则有赖于人们对于大一统的中层次语言的信仰有多坚持。此两种语言无论在系统开发还是在应用开发中都非最优选。目前C#出现一些迹象，引入一些动态语言特性如cmdlet，又强化系统编程能力，想上下通吃。这是一条不归路，必会使C#变得更加复杂怪异。
本文地址：http://com.8s8s.com/it/it26349.htm