分类： C/C++
2007-07-12 18:58:38
什么是高级C++？
——软件工业化时代的C++价值观
孟岩
《程序员》杂志社
开门见山
主要论点：
1. C++本质上是一种重“创新”而轻“生产”的语言，到目前为止仍然是主流语言中最适合技术创新的一个；
2. 1995年之前，整个软件产业处于“创新为王”的阶段，C++是最适合这个阶段的语言，这是C++红极一时的大背景和根本原因。
3. 1995年发生了一系列影响深远的事件，软件产业整体上转向工业化，为了支持工业化，创新的重点由技术创新转向体系创新。然而C++没有能够迅速适应这一变化。
4. 今天，C++应当准确定位，弥补不足，有针对性地发展，它将仍然是最重要的几种工业级语言之一。
从一本书说起
James Coplien，Advanced C++ Programming Styles and Idioms, Addison Wesley, 1991
—— 市面上唯一一本名副其实的“高级”C++书（Scott Meyers）
●面向对象特性的运用和把握
●面向对象的程序风格
●动态特征的运用和超越
●符号语言模拟
●设计模式
这本书代表了当时专家们对于“高级C++”的理解，换句话说代表了当时C++社群的一个审美价值取向。我们看到了什么？技术、技巧、风格、模式，但没有与 工程相关的东西。更有意思的事情是，这本书的中文版12年后被剽窃出版，此时书中对于C++面向对象能力发挥到了我当时没有想到的程度。这说明即使在 template被广泛应用之前，C++语言的技巧性就达到了如此的高度。然而耐人寻味的是，书中最高深的技巧从来就没有在C++实践中流行过。
另一本书...
Scott Meyers, Effective C++ ，1991年第1版，1998年第二版，2005年第三版。
●来自教学经验
●最初想开发一个代码扫描工具
●包含实际工程建议
●历史上最重要的C++著作之一
这本书出版的同时，还有一本在C++历史上影响更大的书问世——Scott Meyers的Effective C++。这本书并没有过多地探索语言技巧，而是探讨实践中应当遵循的规则，或者换句话说，探讨怎样在应用这种语言的同时保持软件的质量，提高开发效率。这本书的内容被整个C++社群熟知并吸收，至今仍在翻新，影响着更多的人。
还是在1991年...
●“按照1991年3月C++程序员增长的速度计算，到1996年5月，全世界每一个人都将成为C++程序员。此后我们将不得不教外星人学习C++。”
●问题：当时人们为什么如此疯狂地学习一种新语言？
答案很有趣：大部分人是盲从。但他们所追随的人并非等闲之辈，几乎所有在AT&T Bell
Labs、Sun、Borland、IBM、Microsoft的C语言大师都转向C++（Brain Kernighan，Jon
Bentley，Peter van der Linden）。而这些人转向C++，不是因为他们知道Effective
C++，而是因为他们知道Advanced C++。什么意思呢？就是说人们转向C++，是因为C++充满了令人兴奋的新技巧和未知的创新空间。
1991年...
●5000行C代码可以写一个完整的应用程序，获得数万$的回报；
●一个TSR式的Help程序可以以shareware的方式通过磁盘发行，开发者银行户头里会收到大量汇款；
●John Carmark和Michael Abrash正在各自擅长的方向上不断创新。Doom发行后，id获得收入一度超过微软销售额。
C++历史选择中“创新”压倒“生产”
“相信程序员”；
Be an enable language;
Zero overhead；
STL投票的通过；
偏特化的引入
多继承
Generic/Generated/Meta
IOStream库的设计
Loki/Boost
counted_ptr被否决
可选GC方案被否决
加入类似delegate的对象方法指针提议未引起关注；
virtual关键字
exception机制
缺乏Thread, Network, Regex, DB...等标准库
没有ABI规范
孱弱的RTTI
并不是事后诸葛亮式的谴责，这就是C++的历史选择，无所谓对错。
C++重创新轻生产，重技巧轻规范，语言上的创新试验直到1996年ANSI C++标准草案落地才结束。直到2001年Modern C++ Design出版，人们还不断地发现新的语言运用技巧。我们每个人都经历过这个阶段，在实践中发现一个问题，想方设法用尽各种语言技巧来克服它，成则欣 喜，败不气馁。我们都曾经相信，C++中一切问题都可以优雅地解决，只有想不到，没有做不到。问题是，从Advanced C++到Modern C++ Design，许许多多令人第一眼看上去无比惊喜的技术，最后在实践中被大范围推广运用的少之又少。C++大师们说这是教育问题，真的是这样吗？
C++社群的价值观
●用优雅的技巧解决复杂问题
●自己动手，丰衣足食
●决不让运行时效率蒙受半点损失
●妙者为王
“管理一群C++程序员就像放牧一群骄傲的猫。”——B. Moo
“C++程序员是高速公路上穿着短皮茄克，带着墨镜，抽着雪茄，挥舞着铁链的英勇无畏的摩托骑士。” ——VC产品经理
1995年：转折点
●Windows 95问世：GUI时代、保护模式操作系统时代、多线程时代的到来，是推动软硬件规模迅速膨胀；
●Netscape Navigator vs. Internet Explorer: Web的兴起将人类一下子拖入互联网时代, 个人与企业应用软件网络化；
●Java诞生：提供了网络时代、跨平台时代优于C++的企业应用软件开发语言；
●COM时代到来
●Delphi诞生：创新与工程原则平衡的典范；
1995年：C++全盛时代
●C++标准草案接近完成，语言基本稳定；
●C++工具大战结束：来自商业竞争的动力消失，MFC获胜；
●很多主流软件厂商转向C++，C++开始在大范围内被用于大规模软件开发；
●一切迹象表明，软件产业的重点将有创新转向生产。但是：C++社群在指导思想上并没有发生相应的变化。
我们的历史失误
●C++社群从来没有联合起来支持任何一个跨平台的二进制组件标准（如COM/SOM/CCM）和基础库（如Apache APR、ACE OS Wrapper）；
●C++社群从来没有联合起来支持任何一个跨平台的C++虚拟机、解释器、内存检测工具和错误录像工具，也从来没有促成过一个安全的库；
●Boost出现于1999-2000年，而在此之前的跨平台C++库都没有获得广泛的支持；
●钟情于用C++语法（无论多么复杂和稀奇古怪）完成所有的任务，却丢掉了老祖宗C语言的看家法宝——Little Language；
●对于风格争论不休，对于明显的技术进步拒不接受，对于很多后来被证明并不实用的技巧趋之若鹜。
没有跨平台的基础库，就没有跨平台的动态模块加载机制；
John Spencer夭折的书《The Art of C Programming》，GoF的Interpreter模式；Little Language实际上具有反映计算机本质的一些东西，现在却成了很少为C++程序员所采用和熟悉的工具。
2005年，C++的现实处境
●在系统编程领域仍然强势；
●套装软件主流开发语言之一；
●嵌入式开发领域进展较快；
●游戏引擎开发主力；
●科学计算方面略有一席之地
●遗留项目的维护；
●在企业应用开发领域快速收缩；
●Web开发中的影子语言；
●从高校主流教学中退潮；
●整体水平仍然不高，很多企业急于摆脱；
●最致命的：真正了解和熟练掌握C++的人太少；
案例：1. 国外一家公司花高薪聘人，要么能维护目前百万行规模的代码，要么把它转成Java；
2. IBM Workplace，项目一开始C++/Java并重，之后C++比重越来越小；
3. 微软与中国电信合作一个项目，客户端软件本来要用C++写，后来赶到产品化周期太长，改用C#，后发先至。
问题何在
●当前的软件产业发展的主要矛盾——各行各业对软件生产标准化、规模化、高质量要求与慢节奏、低效率、低质量的软件开发之间的矛盾。
●解决这个矛盾的关键：组件化体系，成熟的软件生产工具和环境，不断的创新精神。
●C++在外部环境已经发生根本变化的近十年时间里，没有抓住这个主要矛盾。
重新评估我们的C++价值取向
重新评估“高级C++”的现实含义：
- 简洁有效优于惊世骇俗；
- 开放灵活优于保守固执；
- 帮助他人优于凸现自己；
- 领域创新优于卖弄技巧；
六个建议
●学会与现实和谐共处；
●尽快面向不同领域建立跨平台构件标准；
●支持各领域已经形成的基础库不断完善；
●支持相关工具厂商，迅速完善工具链；
●支持动态语言的发展；
●面向产业挑战创新发展；
与现实和谐共处
●承认C++只适合这个世界的一部分工作，快乐地与其他语言共同协作；
●告别妄自尊大和保守傲慢；
●尊重其他社群的专业能力和成绩；
●坦率承认C++在很多场合并非理想选择；
●在C++擅长的领域保持锐意。
跨平台构件标准
●C++迈向未来的关键技术步骤；
●尽可能支持现有的成熟方案；
●在不同尺度的平台上可能需要不同的标准；
支持成熟的基础库
●基本组件：STL和Boost（部分）
●网络和系统编程：ACE
●分布式计算：ICE
●GUI：Qt
●Windows：MFC/ATL/WTL
●科学计算：MTL
完善工具链
●C++用的GC；
●Code Review工具；
●内存错误排查工具；
●测试工具；
●MDA工具；
●文档工具；
●持续集成工具；
●运行录像工具。
支持动态语言
●动态语言是软件技术发展的一个重要方向，几年后会成为主流。
●目前几个流行动态语言天生与C/C++具有亲缘关系；
●加强对动态语言的友好性，是C++未来发展的一项重要任务；
●从这个角度来看待C++/CLI，我们应该持积极态度；
●Little Language问题；
