什么是高级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问题;