博文

【Scott Meyers】C++5×5断想之二:C++历史上最重要的文献 (2006-12-12 22:23:00)

摘要:【Scott Meyers】C++5×5断想之二:C++历史上最重要的文献   原文地址:http://www.artima.com/cppsource/top_cpp_publications.html。译文发表于《程序员》2006.12。 作者介绍 Scott Meyers,C++顶级权威之一,为世界各地客户提供培训和咨询服务。出版有畅销的Effective C++系列图书(《Effective C++》、《More Effective C++》和《Effective STL》),设计了创新型的Effective C++ CD,Addison Wesley的Effective Software Development Series顾问编辑,The C++ Source (http://www.artima.com/cppsource/)咨询板块专家。布朗大学计算机科学博士,他的网站是www.aristeia.com。    在本系列的上一篇文章里,我列出了我认为最重要的五本C++图书,但大量有关C++的重要文献并非来自图书。比如期刊、杂志、网络上的文章;博士论文、会议纪要;新闻组帖子;博客;标准化文档等很多很多。它们对C++的进步与繁荣作出了巨大贡献。我没有读全,甚至谈不上读了大多数,但作为C++的长期关注者,我还是阅读了很多这类文献。在本期里,我将评选C++历史上最重要的五部非图书类文献。和上期评选图书一样,我仍然将数量限制为五,尽管我没有写出过重要到能上这个榜的东西,但仍然将自己列入了候选队伍。以下文献按时间为序。 一个让我无可回避的逻辑范畴两难问题是:如果文献A的思想对C++直接影响很小,但文献B的作者读到了A,将这个思想引入了B并产生了巨大影响,那么到底哪个文献更重要,A(“发明者”)还是B(“繁荣者”)?我最终选择了B,并不是因为这种做法天然就正确,而是因为我不想花力气拼命追查下列文献作者的思想是否从别的文献继承而来[注释1]。反过来,我随便翻到C++语言规范的某页。大家知道,const member functions里的const是不彻底的:指针数据成员自动变为const,但指针所指的数据本身不会。借鉴这个规定,我假设公布在下面的名单里的文献重要,而忽略它们引用的基础物(以及我所不知的其他文献)......

阅读全文(3799) | 评论:0 | 复制链接

Linux Journal对Bjarne Stroustrup专访 (2006-11-29 23:49:00)

摘要:Linux Journal对Bjarne Stroustrup专访 罗翼 翻译  荣耀 指导 Linux Journal(以下简称LJ):您多大年纪了?成家了吗? Bjarne Stroustrup(以下简称BS):我今年51岁了,已经结婚并且有2个小孩,他们现在都在大学读书。 LJ:Bjarne先生,能不能简单地谈谈您年轻时的情况?何时何地出生?在哪里求学? BS:我出生在丹麦的奥尔胡斯市。我的家庭并不是一个书香世家,可我在学校的成绩却很好。所以我继续上了我们本地的高中然后又进入奥尔胡斯大学继续学习。在奥尔胡斯大学,我获得了数学硕士学位,同时培养了我对计算机科学的兴趣。奥尔胡斯是日德兰半岛东海岸的一个拥有25万人口的美丽的城市。和那时所有的男生一样,我在我们公寓的院子里玩耍,在大街上分发报纸和牛奶赚些零花钱,踢足球,在夏日的周末骑车去海边,学会欣赏郊外的森林美景,宛若一名“童子军”。在我大学快要毕业的时候,我微程序设计(microprogramming)越来越感兴趣,然后我就去了英格兰,因为那里有更好的计算机。最后,我在剑桥大学获得了博士学位。 LJ:那您现在住在哪里? BS:我现在住在新泽西的一个名为Watchung的郊区中。这是一个小巧、安静并且拥有许多树林的地方。夏天当你从空中俯视它的时候,几乎是满眼绿色。当我在贝尔实验室工作的时候,从Murray Hill到这里有10分钟车程;而当我到AT&T工作后,从Florham Park开车到这里需要大概30分钟;这里距纽约大约35公里。过去我常能从我家院子的拐角处看到世贸中心的楼顶。 LJ:这儿链接了一个文件,表示您名字的正确发音,它是由您本人录音的吗? BS:是的,是我自己录的音。 LJ:当你还是一个少年时,家中是否有计算机呢? BS:没有。那时离计算机的普及还太早了。那时的计算机非常昂贵,只有在一些大学和大型的公司内才能见到。我见到的第一台计算机是我大学数学系的GIER,它是一台旧的丹麦计算机,有一个房间那么大,程序都写在磁带上面,我用它学习Algol 60程序设计。 LJ:每一个著名的人物都有自己的开始。拿比尔.盖茨来说,他的开始就是用学校买的Basic编译器开始写程序。那么您的开始是什么呢? BS:我认为在我的发展生涯中最关键的一个项目是在剑......

阅读全文(4413) | 评论:0 | 复制链接

BS_CPUMagazine对Bjarne Stroustrup的专访(2006-11-29 23:49:00)

摘要:  BS_CPUMagazine对Bjarne Stroustrup的专访 荣耀 蒋贤哲  译 通常情况下,假如你看到了一个成功的产品或标准,那就会有一个“幕后设备”至少为其做部分支撑。丹麦程序设计师Bjarne Stroustrup于80年代早期在AT&T设计的C++编程语言就是这些幕后设备之一。在过去的20多年间,C++是许多科技和计算进步以及产品的驱动力。Stroustrup如今依然是AT&T实验室计算机科学家,同时还是大规模程序设计研究部门的负责人,最近他和CPU谈论了C++编程语言的若干方面。(译注:Stroustrup如今已经受聘为Texas大学教授,不过AT&T仍然保留了他的位置) Q:在剑桥大学取得计算机科学博士学位之后,您是把设计一种像C++这样的编程语言作为目标,还是另有其他目标? Stroustrup:我的目标是关于构建分布式操作系统的,C++则被设计为实现该项目标的一种工具。 Q:是什么激发您设计C++呢?随着语言的演化,这些思想是否仍有意义? Stroustrup:我对C++的主要目标是能够在代码中直接表达思想,并且使之以接近最优的性能运行。换句话说,就是可以写出既优雅又高效的程序。如今这依然是我的目标,在我感兴趣的许多领域,C++都可以使我做到这一点。特别要提到的一点是,我仍然在实验分布式系统。 Q:最近关于C和C++的变化好像正在促使这两门语言进一步分离,这是件好事吗?或者您希望看到这两门语言走得越来越近? Stroustrup:我希望这两门语言能够合为一体。我看不出有什么哲学上的原因不这么做。对于使用户社群消除不兼容方面,我看到许多实实在在的便利。尽管这种合并在技术上有一定难度,但我认为在技术上是可行的。至于在政治上是否可行则是另外一回事。可能有人会反对我这个回答中的各个声明,我很快就会将一篇探讨C和C++之间关系的论文摆到我的主页[www.research.att.com/~bs/homepage.html]上。 Q:您认为C++为什么现在还能如此流行?在创建C++之后,您可曾料想到20年后还在继续讨论这门语言? Stroustrup:C++有着惊人的表达能力,许多人也的确知道该如何运用它。当今很多计算、通信和商业应用的基础设施都......

阅读全文(3611) | 评论:0 | 复制链接

Rogue Wave对Bjarne Stroustrup的专访(2006-11-29 23:47:00)

摘要:Rogue Wave对Bjarne Stroustrup的专访 荣耀 译  《程序员》2003/06 RW:C++在Internet时代还有意义吗? Bjarne:那是当然。C++代码不适合下载到不安全计算机中,但大多数计算情况并非如此。  对于涉及系统编程和资源受限和/或性能要求严格的许多应用来说,C++是最佳语言选择。Google就是一个例子,支撑小型设备的嵌入系统则是另外一个范例。  此外,还有许多程序并不直接和Internet打交道,对它们而言,世界并无显著变化。  RW:鉴于.NET平台中立的语言已经摆上台面,您认为这对C++将会产生怎样的影响? Bjarne:对C++社群会有一些影响。一些程序员从事和特定运行环境(例如.NET、某种特定嵌入系统或UNIX变体)密切相关的编程。对于他们来说,和平台平滑地集成,就成了需要考虑的头等大事。 在微软.NET世界里,C++受到了足够重视,它仍将是一门举足轻重的语言,但在很大程度上,重心将不可避免地集中于和平台集成以及同以其它语言编写的代码进行互操作。从更长远的观点来看,人们将会获得某种程度的语言中立,而付出的代价则是严重的平台相依。这将会抑制对C++较新成分的试验,但是,鉴于为数众多的程序员只是不可理喻地使用C++的一个有限子集,所以,从短期来看,.NET可能实际上会成为“更好地使用C++”的一个激励因素。  换句话说,我的内心和那些为平台中立和可移植性而奋斗的程序员紧密相连。对于这些程序员来说,轻巧的接口和平台中立的库至关重要。ISO标准则是纽带,它将各C++社群分支维系在一起,并阻止语言四分五裂为混乱的专有方言。  RW:ISO/ANSI C++标准委员会开始讨论修改和扩充C++语言和库。您最希望看到什么样的扩充,抑或您最反对什么样的扩充? Bjarne:我的指导思想非常简单:对于语言的扩充,我们应该小心谨慎,深思熟虑,而对于标准库的扩充,我们应该把握时机,积极进取。我的理由几乎同样简单:我们希望提高可移植性和稳定性,而修改语言是做不到这一点的。库就不一样了,假如我们拿到手的是一个烂库,我们可以把它扔在一边,而采用一个更好的替代品,也可以自己创建或购买一个“比从编译器厂商那儿得到的”更好的库。  如今,人们......

阅读全文(3520) | 评论:0 | 复制链接

Developpeur Reference对Bjarne Stroustrup的(2006-11-29 23:47:00)

摘要:Developpeur Reference对Bjarne Stroustrup的采访 荣耀 译 1.C++的ANSI/ISO标准化过程时间很长,直到1998年才完成。对于没能在更短的时间内完成该项工作,您感到遗憾吗? 您认为这减缓了C++的“渗透”吗(举个例子,在教育领域,许多人继续教授C语言,并声称C++还没有被标准化,这种境况真让人恼火)?  您认为这减缓了C++的进化了吗(标准库的更好的进化,对分布式计算的考虑……)?  Bjarne Stroustrup:当然了,假如C++标准能够更早地完成,情况会很好,但实际上C++标准化过程并不比其他标准来得慢。正儿八经的标准化所需的时间,要比大多数人所想象的时间长,因为要满足那么多人和组织的要求。  许多人过去 — 一些人现在 — 还这么教学:要么把C++当成一种非常低级的语言,集中于“和C共享”的那些特性上,或者把它当作一种表达类层次结构的语言。两种方式都没有突出C++最伟大的力量。更糟糕的是,这些方式通常在那些“对程序员帮助不太大”的C++组成部分上花费太多的时间,而未能教授关键的技术和语言设施,以利于更有效地使用C++。标准库里的容器和算法,以及用于资源管理的异常(exceptions)的使用,就是一些常常被忽视的“关键的主题”的例子,或被错误地认为过于“高级”。  我认为,与漫长的ISO标准化过程相比,这种教学上的失败对C++的应用所造成的伤害更大。显然,假如在1985年我们就有标准库可用的话,情况会好很多,但事实并非如此。如此一来,我们也就不知道该怎么来设计和实现一些通用、优雅和高效的东西。  听到有人说C++还没有被标准化,真让人感到悲哀。1998年ISO标准被批准,其实自1996年起,就没有向语言或标准库中添加新的重大特性了,在计算领域,这个时间可不短。  至于进化的速度,它受限于我们对问题的理解,尤其被我们的教学能力(教授“很好地使用这种语言”的能力)所限。我不认为语言能够或者应该比现在这个样子进化速度快很多。实验性的语言可以迅速演化,因为它们几乎没有什么用户,而象C++这样的主流语言,不能比它的用户社群变化得还快,“稳定压倒一切”。 2.对于C++接下来的版本,好像您更倾向于扩展标准库而不是进化语言的语法。可以......

阅读全文(3272) | 评论:0 | 复制链接

专访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:标准化是个缓慢的进程,常常聚焦在琐细的......

阅读全文(4226) | 评论:0 | 复制链接

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++的库来替代,它将为你正确 地处理很多与回调机制相关的事务,包括回调类、槽位和......

阅读全文(3367) | 评论:0 | 复制链接

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社团在理解新概念上的失败异常相似......

阅读全文(3193) | 评论:0 | 复制链接

Bjarne访谈:抽象与效率 (2006-11-27 18:45:00)

摘要:抽象与效率  蒋贤哲 译  提升抽象的层面  Bill Venners(以下简称Bill):我最初是从Borland的一个教学录像“World of C++"”开始学习C++的。在该录像开头的简短片断中,你说你正致力于C++方面的工作是提升编程过程中的抽象层面。  Bjarne Stroustrup(以下简称BS):是的。  Bill:提升抽象层面意味着什么呢,一个高的抽象层面为什么会有良好 的表现呢?  BS:较高的抽象层面不仅仅在C++中表现良好,在普遍情形下都具有良好表现。我们希望能够在考虑问题的层面上来处理这些问题。如果我们能够以此种方式来处理这些问题,那么在理解这些问题的方式与实现其解决方案的方式之间将不存在鸿沟。我们能够比较容易地理解别人的代码,而不必使自己犹如编译器 一般。     抽象是一种理解事物的机制。例如,用数学方式来表达一个解决方案则意味着我们真正理解了这一问题。我们不是推出大量的方法针对于特定的情形进行试验。人们经常会仅仅针对一个特定的问题提出解决方案。但是,除非我们试着对问题进行归纳概括并将一个问题看作一类普遍问题的范例,那么我们将会遗漏掉“针对于我们特定问题的解决方案中的”重要部分,而且不可能找到将来对我们具有帮助的概念和一般性 的解决方案。如果某些人具有一条理论,例如有关矩阵操作的一条理论,那么你就可工作于这些概念的层面之上,而且你的代码将变得简洁、清晰且正确的可能性会更大,只需编写少量的代码,而且便于维护。  我相信提升抽象层面对于所有实际的科学探究都具有基础性的作用。尽管我不认为提升抽象层面是一个有争议的观点,但是由于认为较高抽象层面的代码呈现出不必要的低效率,所有人们有时会认为这是一个存在争议的观点。例如,我两天前收到了一个听过我报告的人 发来的电子邮件,在这次报告中我倡导使用一个具有适当线性代数支持的矩阵库。他说,“使用矩阵库与直接使用数组相比所耗用的资源要多多少?我不敢确定我能承受得起这一耗用。”令他非常惊异的是,我的答案是,“如果你想达到我所指出的效率,你不能直接使用数组。”  比最快的代码还要快的代码就是根本没有代码。通过对矩阵处理操作的抽象,你可为编译器提供足够的类型信息,从而能使......

阅读全文(5051) | 评论:0 | 复制链接

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虚......

阅读全文(3227) | 评论:0 | 复制链接