博文
专访C++之父Bjarne Stroustrup (BS_CView)(2006-11-29 23:45:00)
摘要：
专访C++之父Bjarne Stroustrup
采访：虫 虫 翻译：ALNG
感谢C-View.org准许转载
编者按：在C++ View第1期中我们介绍了这位C++之父，相信大家都很熟悉了。这次，小编对这位大人物进行了专访，非常感谢Stroustrup博士的精彩回答和耐心的解释。感谢cber添补的问题，和对小编中国式英语的纠正。同时还要感谢ALNG精彩的中文翻译，这能方便大家更好地理解Stroustrup博士的深邃思想。关于翻译的一些细节问题，小编与ALNG争吵了整整一天，大体上达成了一致。有些需要说明的地方，都在文中加入了相应的注释。不过小编还得声明，Stroustrup博士回答的内容均以英文为准。
C++ View：C++的ANSI/ISO标准化标志着C++的成熟。能告诉我们在标准化过程中，您感到最难忘、最快乐以及最遗憾的事分别是什么吗？
Bjarne Stroustrup：标准化是一个极其有价值的重要活动，它在很大程度上被低估，困难重重。通过标准化，C++变得更好了，还获得了有着惊人表达力的标准库。编译器提供商总是想锁定用户，正式的标准化则是用户拥有的为数不多的防御手段之一。
很难挑出特定的事。委员会的大多数工作形式上都是发现、提练、建立信任的过程，要花时间。不过最重要的事一定是1990年对以The C++ Programming Language第二版（其中引入了模板和异常机制）作为参考手册来标准化C++的初次投票或1998年批准ISO标准的最终表决，两者之一。
没有任何负面或遗憾的事可以与这些积极的投票相提并论。所谓“遗憾”的事，要么是细微的技术细节，要么是（暂时）分化了委员会而使进一步的进展更加困难的讨论。我本来是反对C风格的cast，也不想引入仅允许整型的静态常量成员在类中初始化的机制。不过这些只是无关大局的细节。【注：cast翻译成什么好呢？其本意是铸造、打型，诸位以为，“映射”、“转换”、“型铸”哪一个翻译更贴切呢？或者有其他更好的翻译？】
我期待着另外一次重要表决。明年某个时间委员会将决定ISO C++的未来方向，这可是头等大事啊！
C++ View：C++的标准化为何会困难重重？另外可以再谈谈委员会里的工作进程吗？
Bjarne Stroustrup：标准化是个缓慢的进程，常常聚焦在琐细的......
Bjarne访谈：The C++ Style Sweet Spot(2006-11-27 18:49:00)
摘要：The C++ Style Sweet Spot
罗翼 译 蒋贤哲 校
从C往上
Bill Venners：在一次采访中，您曾说过：“C++社群正在逐渐消化C++标准所提供的基础设施。通过重新思考C++使用风格，在代码的编写、正确性、可维护性以及效率上都可以得到很大改进”。请问C++程序员该如何重新思考C++的使用风格呢？
Bjarne Stroustrup：通常情况下，指出不要做什么比指出要做什么容易得多，所以我也将采用这种方式来回答你的问题。很多人认为C++只不过是对C作了一些细小的扩充而已。在他们的代码中，充斥着原生指针和原生数组，他们将原先在C语言中使用malloc的地方换为使用new。总而言之，他们的代码的抽象层次很低。使用C形式的编码风格是一种使用C++的方式，可是这种方式并不能有效地利用C++。
我认为一种较好的使用C++的方法就是采用标准库提供的一些基础设施，例如使用vector代替原生数组。vector知道自己的大小，而原生数组就做不到。你可以方便地隐式或显示地改变一个vector的大小。如果需要改变一个原生数组的大小，你必须利用realloc、malloc以及memcpy等函数显示处理内存相关的问题。再例如利用内联函数代替宏，你就可以避开一些与宏相关的问题。还有，使用C++中的string类而不是显示地去手工操纵一个C字符串。如果在你的代码中出现了大量的转型操作符，那么几乎可以肯定代码中存在某些问题，因为你已经从一种较高的、基于类型的抽象层次下降到了一种低级的、直接与位和字节打交道的层次了。你不应该纵容这种情况经常发生。
脱离低抽象层次的风格并不意味着你需要从头手工打造一些基础的类来开始你的工作，作为替代，你可以使用由类库提供的设施。标准库是最容易想到同时也最显而易见的一个类库，当然，同时也还存在着许多其它致力于不同专业领域的库，例如数学或系统程序设计。作为一个示例，你并不需要在C层次编写你的线程代码，你可以使用一个C++线程库，例如Boost.Threads，而且在C++世界，线程库的数量是相当多的。再例如如果你需要使用回调函数机制的话，你最好不要直接 采用原生的C函数风格，而可以使用一个名为libsigc++的库来替代，它将为你正确 地处理很多与回调机制相关的事务，包括回调类、槽位和......
Bjarne访谈：现代C++风格(2006-11-27 18:47:00)
摘要：现代C++风格
罗翼 译 蒋贤哲 校
多重继承和纯抽象类
Bill Venners：我在1991至1996这5年间，几乎一直 仅仅使用C++编程。在那时，我认为多重继承唯一目的就是让我能够从多个基类中继承它们各自的数据和函数 — 不管是虚 拟函数还是非虚拟函数。那时候，我和我使用C++的同事几乎从未想过可以使用一种不含任何数据而仅包含 纯虚函数的类，也就是现在Java中被称为接口的东西。最近您好像又越来越多地提起了抽象类这个概念，我想问问是不是最近在实验的过程中发现了一些我们以前未曾注意到的对纯 接口类进行多重继承的好处，抑或是您认为我们以前对抽象类重视得不够？
Bjarne Stroustrup：我在对人们解释这个问题的过程中遇到了很多问题，而且我也一直不能理解为什么让人们理解这个问题是如此困难。自C++出现那天起，就存在着包含数据成员的类和不包含数据成员的类。在过去，人们强调利用一个最基础的设施以及该设施内部的 东西来构造软件系统，而那个“最基本的设施”通常就是抽象基类。从80年代中叶到80年代末，那些仅由 虚拟函数组合而成的类通常都被称为ABCs（Abstract Base Classes 抽象基类）。1987年，我在C++中加入了 纯虚函数的概念，一个纯虚函数必须被其派生类重写。借助此概念，你可以在一个C++类中通过将其成员函数 声明为纯虚函数的方法表明该类是一个纯接口类。从那以后，我就一直强调在C++中，有一种主要的使用类的方法就是让该类不包含任何状态， 而仅仅作为一个接口。
从C++的 角度来看，一个抽象类和一个接口之间没有任何区别。有时，我们习惯使用“纯抽象类”这个词来表示某个类仅仅只含有纯虚函数（不包含任何数据成员），它是抽象类的最常见的形式。当我试图向人们解释这个概念时，我发现如果我不先向他们介绍 纯虚函数这个语言中被直接支持的概念，人们就很难接受它。有些人仅仅因为可以在基类中放入一些数据成员，就觉得他们必须这样做。他们这样做，就等于构造了经典的不稳定基类，当然同时也就 招致该结构所带来的一切问题。当我向人们介绍C++中直接支持抽象基类的概念时，情况稍微好一些，不过仍然有许多人不能理解它。我认为这是由于我自身的原因所造成的教育上的失败 — 我低估了做这件事的难度。这与早些时候Simula社团在理解新概念上的失败异常相似......
Bjarne访谈：抽象与效率 (2006-11-27 18:45:00)
摘要：抽象与效率
蒋贤哲 译
提升抽象的层面
Bill Venners（以下简称Bill）：我最初是从Borland的一个教学录像“World of C++"”开始学习C++的。在该录像开头的简短片断中，你说你正致力于C++方面的工作是提升编程过程中的抽象层面。
Bjarne Stroustrup（以下简称BS）：是的。
Bill：提升抽象层面意味着什么呢，一个高的抽象层面为什么会有良好 的表现呢？
BS：较高的抽象层面不仅仅在C++中表现良好，在普遍情形下都具有良好表现。我们希望能够在考虑问题的层面上来处理这些问题。如果我们能够以此种方式来处理这些问题，那么在理解这些问题的方式与实现其解决方案的方式之间将不存在鸿沟。我们能够比较容易地理解别人的代码，而不必使自己犹如编译器 一般。
抽象是一种理解事物的机制。例如，用数学方式来表达一个解决方案则意味着我们真正理解了这一问题。我们不是推出大量的方法针对于特定的情形进行试验。人们经常会仅仅针对一个特定的问题提出解决方案。但是，除非我们试着对问题进行归纳概括并将一个问题看作一类普遍问题的范例，那么我们将会遗漏掉“针对于我们特定问题的解决方案中的”重要部分，而且不可能找到将来对我们具有帮助的概念和一般性 的解决方案。如果某些人具有一条理论，例如有关矩阵操作的一条理论，那么你就可工作于这些概念的层面之上，而且你的代码将变得简洁、清晰且正确的可能性会更大，只需编写少量的代码，而且便于维护。
我相信提升抽象层面对于所有实际的科学探究都具有基础性的作用。尽管我不认为提升抽象层面是一个有争议的观点，但是由于认为较高抽象层面的代码呈现出不必要的低效率，所有人们有时会认为这是一个存在争议的观点。例如，我两天前收到了一个听过我报告的人 发来的电子邮件，在这次报告中我倡导使用一个具有适当线性代数支持的矩阵库。他说，“使用矩阵库与直接使用数组相比所耗用的资源要多多少？我不敢确定我能承受得起这一耗用。”令他非常惊异的是，我的答案是，“如果你想达到我所指出的效率，你不能直接使用数组。”
比最快的代码还要快的代码就是根本没有代码。通过对矩阵处理操作的抽象，你可为编译器提供足够的类型信息，从而能使......
Bjarne访谈：优雅和其他设计理念(2006-11-27 18:43:00)
摘要：优雅和其他设计理念
蒋贤哲 译
在编码之前思考
Bill Venners（以下简称Bill）：在与Biltek的一次访谈中，你说，“我不是使用支持工具进行巧妙设计的信徒。然而，对于系统性使用数据抽象、OOP、泛型编程我则是一个坚定的支持者。那些只是坐下来编写一页页代码，而没有全局性设计、且不支持类和模板的人只不过是在浪费时间和制造不必要的维护问题。”那么你将推荐何种程度的前瞻性设计，在编码之前我们应该思考多少呢？
Bjarne Stroustrup（以下简称BS）：这在很大程度上取决于问题的规模。如果你须编写一个今天下午所需的小型程序，那么设计将可能只需要信封背面那么大的地方。如果你正在编写一个必须运行多年并需耗费多年 才能创建成的系统，那么很明显，必须做大量的前瞻性设计。如果项目牵涉了大量人员，那么就须作更多的前瞻性设计。但是，系统规模越大，前瞻性设计也将变得愈加困难。设计工具并没有为你提供多少反馈，所以我倾向于这样的观点，即你应当先编写一个小型系统，然后再逐渐将其扩展为一个比较大的系统。规律表明非常成功的大型系统都是由正在运行的相对小 的系统逐步发展而来。你可以反复地运用这一规则。
一些人可能会认为我是在谈论创建原型。尽管在一定程度上如此，但是这并不是我所谈论的全部，因为原型也可能是一个陷阱。如果你是雇佣一种不同类型的开发人员、使用一种不同的工具、以及与实际应用程序完全不同的工作量来创建一个原型，那么你就可能遭遇真正的难题。例如，在开发一个支持十个用户的原型中，你可能需要每个人负担更多的硬件 和软件，需要更多的有经验的开发人员，而与原本开发一个必须支持一万个用户的原型相比，前者的负担要多于后者。通常你可以忽略了一个原型中那些不怎么方便的标准和兼容性问题。当然，此时还有一些方法中的问题没有膨胀起来。
有时你可以创建一个系统的部分功能以便对其进行测试。我个人则非常倾向于尽早进行整合测试。例如，在一个分布式系统中，你可决定使用何种工具，并编写“Hello, world”的逻辑上的等价程序，你可以从系统各个不同部分的应用程序中的最小例子开始进行测试，并让它们互相进行测试和通信。就是此刻，你会发现你的JAVA ORB不能和你的C++ ORB进行通信，或是HP上的JAVA虚拟机不能和SUN上的JAVA虚......
Bjarne访谈：C++热点问题一席谈-荣耀/刘未鹏(2006-11-27 18:41:00)
摘要：C++热点问题一席谈
— Bjarne Stroustrup 2005新春专访
荣耀 访 荣耀/刘未鹏 译
荣耀: Herb Sutter和Stan Lippman目前正在微软主持C++/CLI的设计工作，意图将动态的、基于组件的.NET编程模型和ISO C++集成在一起。您对此有何评价？您认为C++需要.NET吗？您认为C++/CLI会取得成功吗？
Bjarne: 不，C++根本不需要.NET，C++只需要最小限度的运行时支持，用于new/delete、异常处理以及RTTI等，而且仅当你使用这些特性时才需要。C++程序通常可以使用每一分可用的资源，在硬件上直接跑。C++的这些能力使其非常适合于系统级编程以及嵌入式系统任务。当然，也有些C++应用需要.NET，比如那些为了和微软.NET框架和服务紧密集成而专门设计的应用。然而，C++语言和标准库的宗旨是远离这些平台相关性的纠缠。另一方面，许多.NET设施都依赖于C++，因为除了C++之外，再也找不到更通用、更高效的语言来很好地完成这个任务，从这个意义上说，.NET需要C++。
从“很多人将会使用它”这个意义上来说，C++/CLI是会成功的。使用.NET CLI，开发者选择甚少，而C++则是最佳选择之一，而且很明显在Windows上也是，因为微软给予C++最好的支持。话虽如此，我仍然倾向于在设计系统时保持良好的移植性，而将对平台相关或专有特性的使用限制在特定的代码块中，并使用以ISO标准C++所表达的接口去访问它们。
荣耀: 尽管我现在相信这是一个毫无意义的问题，不过我想我最好还是澄清一下。当我说“C++需要.NET吗？”，我的意思是想问“我们需要.NET来使C++更普及吗？”。这就好比问“世界和平需要美国吗？”，或者，“我们需要美国来维护世界和平吗？”。当然了，我们都不喜欢讨论政治性话题，也许这个比方很不合适。
Bjarne: 政治关乎可行性。从这个意义上来说，我们必须考虑政治，而你的问题当然也是合理的。鉴于微软在软件领域的地位以及它对.NET强大而完全的支持（将.NET的系统接口以CLI来表达），.NET的地位会变得很重要。要想在微软的世界里玩得转的话，C++必须很好地绑定到.N......
程序人生(2006-11-26 23:13:00)
摘要：程序人生
有人问我：什么样的程序才算得上编的好
程序人生， 其实程序就像人生，什么样的程序编的好就好比如什么样的人生比较好呢？学历越高越好还是经验越丰富越好；名声重要还是金钱重要；选择家体还是爱情……它们或许可以共存，或许得经历种种选择，甚至抉择；程序也一样，十全十美的程序基本上不存在，一个程序需要在很多质量属性之间选择；质量与效率成本的平衡。
程序，正确性当然是第一，程序都不能工作还谈质量、成本就没什么意义了。那么人生呢？人必须活着，活着是第一，都死了或者快死了还谈什么人生意义。活着，没有活着，没有生存能力的话，其他方面都没什么好说了。
生存能力，基本可以理解为赚钱，想生存基本上就得赚钱，如果缺吃少穿，那么你还可能去研究数学物理？当然，这里的生存能力还应该更广泛一点。第一、人家觉得你的人生有意义，赞助你完成你的人生，比如赞助你做科研等；第二、你的家庭条件好，你可以在不考虑赚钱的情况下选择你自认为有意义的人生。然而不管自己赚钱、国家或者别人资助或者依靠家庭，这些都是生存能力的体现，没有生存能力，你的人生即将结束，何来人生的意义。生活不是为了活着，但是生活必须要活着，活着是为了生活。
正确性是程序的第一要素，但是这是最基本的，除了正确性，还需要比如健壮性、可靠性、可移植性、易用性、清晰性、安全性、可扩展性等。很不幸的是其他性能之间并不能完全”融合“，它们之间可能存在冲突，安全的代码可能不清晰，可扩展的代码又可能不安全，因此各个属性之间需要平衡。更重要的是，单单考虑这些质量属性甚至还不行，质量得跟实际相结合，你写了质量很高很高的程序得要一年，人家客户要求半个月完成，你老板不炒了你才怪；人家可能不需要那么高的质量，比如人家对健壮性也不是很在乎，当机了人家也不在意，至多重新开始。一般来说，质量高的，效率就低，价格自然就涨，因此他们也需要一个平衡。
&nbs......
IT时代周刊：吴鹰下台内幕(2006-11-26 13:27:00)
摘要：IT时代周刊：吴鹰下台内幕
2006.11.25 来自：IT时代周刊
不过，对于吴鹰不再就任CEO职位一事，UT方面称，这只是公司让吴鹰承担更重要的职能，寻找公司战略选择，而不是因为小灵通的问题。一位接近吴鹰和UT达数年之久的内部人士对《T时代周刊》记者透露，由于当初吴鹰做小灵通做得很强势，分抢了中国移动和中国联通的饭碗，曾经给两者造成了很大压力， UT一度与两者关系很僵。
镁光灯下的吴鹰、饱受赞誉的UT，曾经编织了一个个令人钦慕的美梦。但在今天，当小灵通脱去那层繁华，吴鹰也就失去了那层炫目的光环。而随着UT的代理商贿赂蒙古、印度等一连串商业贿赂案的出现，更是将这昔日的明星企业丑化。而吴鹰从内定的CEO宝座上被董事会否决，也宣告着他从神坛跌落到凡间。UT变数之中，吴鹰已经失去了昔日耀眼的光环。
风云际会的资本市场从来都是缔造神话的梦幻之地。满脸大胡子、被美国《时代周刊》描绘为切·格瓦拉造型的吴鹰，更是裹挟着UT斯达康一度将全球投资机构的目光齐齐聚拢到了中国。
全球主流商业媒体一直没有忘记吴鹰。查阅当年出版的《福布斯》、《商业周刊》、《财富》、《华尔街日报》，我们仍然可以读到吴鹰慷慨激昂、娓娓道来的投资故事、成功经验以及想当年“27美元独闯美国”的气魄。
但，梦终究是梦。
当股票价格从最高91.88美元急速下挫到5.86美元甚至更低的过程中，最先醒来的依旧是吴鹰。股市的重重压力催生了UT 2006年3月来自纳斯达克摘牌威胁的窘迫局面(UT斯达康称，公司推迟提交财报不是股市压力，而是公司内部审计的流程需要)。 7月，UT再次向纳市申请暂缓7天提交公司财务报表。 随后，2005年12月的UT贿赂蒙古国政府官员、2006年4月的贿赂印度政府官员等一连串商业贿赂案日渐浮出水面，再度丑化了步履维艰的UT。
小灵通的无力回天，WCDMA十几亿美元化作泡影，大手笔下注IPTV却再度被稳稳套牢……力图扭转乾坤的吴鹰备感尴尬，心力交瘁之余，其个人能力开始遭遇集体性质疑。
2006年10月，UT董事会否决了原定的吴鹰的全球CEO职位。
UT变数之中，吴鹰已经失去了昔日耀眼的光环。
成也小灵通 败也小灵通
1989年，在......
专访 Bjarne Stroustrup - 荣耀(2006-11-26 11:16:00)
摘要：专访 Bjarne Stroustrup
来源：荣耀 马皓明 译 作者：Bjarne Stroustrup 等级：强烈推荐
发布于2005-10-22 22:54 被读588次 【字体：大 中 小】
Bjarne Stroustrup 其它言论 http://www.royaloo.com/bjarne/bjarne.htm
承蒙孟岩先生允许，本译文引用了他的摘译稿，谨致谢意。
Elden Nelson：如果您现在有机会从头设计C++语言，您会做些什么样的改变？
Bjarne Stroustrup：当然，你永远都不可能重新设计一种语言，那没有意义，而且任何一种语言都是它那个时代的产物。如果让我今天再设计一种语言，我仍然会综合考虑逻辑的优美、效率、通用性、实现的复杂程度以及人们的喜好。要知道人们的习惯对于其喜好有着巨大的影响。现在，我会寻找一种简单得多的语法 — 它可能与人们对“熟悉”和“简单”的混淆认识相悖，我会把对类型系统的侵犯限制在极少的语言构造里，并且用明显“丑陋”的语法来标识它们。（就象我对对新风格的“转型”的处理，比方说，reinterpret_cast<数据类型>(p)就是一个用来描述一种“丑陋”操作的“丑陋”记号）。这样可以很容易地禁止不安全的操作。我还会把核心语言的体积搞得尽可能小一些，包括类和模板的关键的抽象特性，而把很多其它的语言功能放在库里来解决。当然我也会保证核心语言足够强大，使得那些库本身也足以用此核心语言来产生。我可不希望标准库的编写者依赖于普通用户无法使用的额外的语言特性。我还努力使核心语言的定义更加精确。最重要的是，我会在该语言被广泛使用之前尽可能维持一个很长的酝酿期，这样我就可以根据来自真实用户的坚实反馈对它进行改进。这可能是最困难的，因为一旦有什么东西明显出色并且前途光明，它就会被广为使用，此后进行任何不兼容的修正都将变得极其困难。我相信这些思想与我当初设计C++时的理念是非常类似的，它们同样也指引着一、二十年来C++的不断演化。当然，我认为现在还没有什么东西能让我觉得象是“完美的语言”。
Elden Nelson：当您设计C++语言时，您是否借鉴了其他崭露头角的对象语言（例如Modula-2）的思想？
理想是模糊的——看李开复的《做最好的自己》(2006-11-26 01:59:00)
摘要：理想是模糊的——看李开复的《做最好的自己》
大家都应该有一个理想，有人生的一个奋斗目标。李开复老师的书中讲解了很多这方面的相关的东西。
谈到理想的意义：“理想和财富并不冲突，一心追求财富多半适得其反，而一心追求理想却有可能让财富离自己更近一些。理想是引领人生的灯塔；没有理想，就没有坚定的方向；没有方向就没有充实的生活。” 简单的说：你自己都不知道你读书是为了什么，那你还会认真读书？你自己都不知道现在活着是为了什么，那你可能会觉得很孤单寂寞，甚至心理会渐渐的不健康。
对理想的真正理解：“并不是理想都必须像伟人的理想那样宏伟壮丽，而应该是最适合自己的人生目标，是非常个性化的愿景或使命。应该由个人的选择并决定。”我的理解是，你的理想应该根据自己的喜好，自己的条件，从自身实际出发去选择，不应盲目跟从。
如何确定理想，确定人生目标呢？
很多标准，比如，“理想要有价值；理想要符合实际又要有点挑战；尽量摆脱名利羁绊；能够成为自己的智囊，指引自己走向成功。”举个例子：“成为最厉害的黑客”，这种理想就不太好了，虽然有挑战，摆脱名利，让自己更聪明，但价值并不大，除了满足一下自己的虚荣心，让自己愤世嫉俗的思想爆发一下，没有什么了，搞不好哪天被抓了还大喊冤枉。
很多方法，书中谈到一个“心灵感应法”，我不知道是不是真的有效，就不列举了；谈到了用智慧选择成功的方法，概括为七句话：“用中庸拒绝极端；用理智反对片面；用务实发挥影响；用冷静掌控抉择；用学习积累经验；用自觉端正态度；用真心追求智慧。”
虽然理想的标准很多，方法也很多，大家都在追寻探索，但是不可不说的是：理想的选择仍然是模糊的，人生目标是模糊的。一个人积极进取，努力学习成为了科学家，获得诺贝尔奖才发现原来这不是我的理想，我的人生根本不希望是这样的；当一个人通过种种关系当上了镇长、县长、省长才发现当官没意思；当一个老师下海经商赚得大钱才发现原来教育下一代才是我的人生目标。
&nb......