收藏 分享(赏)

如何学好C.doc

上传人:scg750829 文档编号:7511200 上传时间:2019-05-20 格式:DOC 页数:20 大小:98.50KB
下载 相关 举报
如何学好C.doc_第1页
第1页 / 共20页
如何学好C.doc_第2页
第2页 / 共20页
如何学好C.doc_第3页
第3页 / 共20页
如何学好C.doc_第4页
第4页 / 共20页
如何学好C.doc_第5页
第5页 / 共20页
点击查看更多>>
资源描述

1、如何学好 C+,我没有别的办法给你们,唯一的办法就是读书,读大量的书,就可以解决。要把 C+作为日常语言,而不是一种程序语言,这样就好办了。 有人又要问我,那么我应该读什么书才好?没有时间怎么办? 我只能对你们说,没时间的话,就别学 C+了,做你们喜欢做的事。生活中没有C+,也同样美好。 如果你准备学,一定要学好,那么我开个书单,应该问题不是甚大。 首先肯定要读一读 Bjarne Stroustrup 的 The Design and Evolution of C+,了解一下这个语言的历史。接下来就可以看别的书了,但要不停地回头看这本书,看到你不断地学到的新技术是怎么样一点点地被接纳到这个语言

2、中去的。 第一本书因人而异,基础好一些的,可以看 Stanley B. Lippman 的 C+ Primer,这本书非常地巨大,你打星号的部分可以不要看。基础不太好的,可以看 Stanley B.Lippman 的 Essential C+,这本书份量要轻得多,不过四个 C+的范型都讲了,而且讲得非常清楚。 第二本应该停止技术层面的东西,静下心来看看 Pike 和 Kernighan 的 The Practice of Programming,好好地整理一下,在程序设计中应该有哪些注意的事项。这本非常薄的 booklet,可以说是程序员必读的指南。 第三本书,就应该是 Bruce Eckel

3、 写的、候捷译的 Thinking in C+,这本书每过半年我就要重读一遍。可以说每一章都是写得发人深省的,这本书让我感觉到了技术运用的非常高的境界,但是语言非常平实,只要认真地读,即使基础不行,也一定可以懂。我在教课的时候,就是用这本书(面对的学生是零基础)。要更上一层的话,就要慢一步,先要把握 C+设计习惯的良好。这是 Scott Meyers Effective C+和 More Effective C+带给我们的无尽收益。我 More Effective C+买不起,只好花了 10 块钱复印装订了一本“线装本“ ,看起来像葵花宝典(;-))。这两本书是真正的经典,作者对 C+的纯熟,

4、使得语言的风格读起来简直是如饴甘甜,就像他站在对面在讲课。我手中有这两本书的原版 CD,如果有兴趣,可以发 E-mail 到 或在饮水思源投条儿给 gaobo 索要,只要您提供光盘我就给免费烧。如果你已经深刻地理解了 Effective C+和 More Effective C+,那你可以发现,你在众人中已经是鸡群之鹤。可以指导项目运作了,可以编写一切你想做的程序了,可以指出别人看起来不错的代码的大小问题了。如果你能一眼看出有人的代码是对应于“条款 27“或“条款 M6“,那你可真是让本人刮目了。 我已经讲了,如果要写程序,EC+和 MEC+的境界已经足以使你自如应付,可是如果你还不满足,想

5、关注一些理论层面的问题,或是想看看实现的代码,你就不应该错过这几本好极了的书。我是说 Herb Sutter 的 Exceptional C+和 More Exceptional C+,这两本书的难度是非常大的,我对每一条的阅读笔记都是十多页。特别是泛型程序设计的部分,这两本书旁征博引,极尽深入探讨之能事,每每看懂一条,都抹汗一次,大感酣畅淋漓;还有侯捷的 STL 源码剖析 ,以实际的例子一点点地讲解一个 STL 是怎么样实现的,我是刚开始读,不发表评论;而Stanley B. Lippman,Cfront 的实现者之一,执笔写出 Inside the C+ Object Model,我只有一

6、个字,就是基本帅呆了。我从中了解了无数的编译器解释源代码的细节,以及记忆体分配的细节,呵呵,这些都知道了,我还怕什么呢?最近得到了另一Cfront 实现者、C+标准委员会 Koenig 的 C+ 沉思录,看起来非常不错,这里也推荐给大家,但我也没看完,亦无发言权。 最后最后,你们,未来的 C+理论家们,可要记住,Bjarne Stroustrup 的 The C+ Programming Language 无论如何也应该读个四五遍!这是一切 C+的书本的源泉。如果还觉得不够,就向 C+标准委员会订购一本 C+标准。一切中国大陆作者的书,一概不要看(包括我的)。一切 VC+或讲特定的编译器的书,

7、一概不要看。如果需要补 C 语言的课,买一本非常小的 K / Standard C+ stylecin s;而不是这样的:char sMAX; /* Standard C style */scanf(“%s“,s);去看看那些扎实的 C+程序员们推荐的书吧。记住,没有哪本书对所有人来说都是最好的。另外,要写地道的 C+程序,而避免用 C+的语法写传统风格的程序,新瓶装旧酒没多大意义。(遗憾的是,目前在市面上的中文 C+教材中,符合 B. S 的这个标准的可以说一本都没有,大家只好到网上找一些英文的资料来学习了。译者)6. 怎样改进我的 C+程序?不好说。这取决于你是怎么使用该语言的。大多数人低

8、估了抽象类和模板的价值,反过来却肆无忌惮地使用造型机制(cast)和宏。这方面可以看看我的文章和书。抽象类和和模板的作用当然是提供一种方便的手段建构单根的类层次或者重用函数,但更重要的是,它们作为接口提供了简洁的、逻辑性的服务表示机制。7. 语言的选择是不是很重要?是,但也别指望奇迹。很多人似乎相信某一种语言能够解决他们在系统开发中遇到的几乎所有问题,他们不断地去寻找完美的编程语言,然后一次次的失败,一次次的沮丧。另外一些人则将编程语言贬为无关紧要的细节,把大把大把的银子放在开发流程和设计方法上,他们永远都在用着 COBOL, C 和一些专有语言。一种优秀的语言,例如 C+,能帮助设计者和程序

9、员做很多事情,而其能力和缺陷又能够被清楚地了解和对待。8. ANSI/ISO 标准委员会是不是糟蹋了 C+?当然不是!他们(我们)的工作很出色。你可以在一些细节上找些歪理来挑刺,但我个人对于这种语言以及新的标准库可是欣欣然。ISO C+ 较之 C+的以前版本更出色更有条理。相对于标准化过程刚刚开始之初,你今天可以写出更优雅、更易于维护的 C+程序。新的标准库也是一份真正的大礼。由于标准库提供了 strings, lists, vectors, maps 以及作用于其上的基本算法,使用 C+的方式已经发生了巨大的变化。9. 你现在有没有想删除一些 C+特性?没有,真的。问这些问题的人大概是希望我

10、回答下面特性中的一个:多继承、异常、模板和 RTTI。但是没有它们,C+ 就是不完整的。在过去的 N 年中,我已经反复考虑过它们的设计,并且与标准委员会一起改进了其细节,但是没有一个能被去掉又不引起大地震。从语言设计的角度讲,我最不喜欢的部分是与 C 兼容的那个子集,但又不能把它去掉,因为那样对于在现实世界里工作的程序员们来说伤害太大了。C+与C 兼容,这是一项关键的设计决策,绝对不是一个叫卖的噱头。兼容性的实现和维护是十分困难的,但确实使程序员们至今受益良多。但是现在,C+已经有了新的特性,程序员们可以从麻烦多多的 C 风格中解脱出来。例如,使用标准库里的容器类,象 vector, list

11、, map, string 等等,可以避免与底层的指针操作技巧混战不休。10. 如果不必和 C 兼容,你所创造的语言是不是就会是 Java?不是,差得远。如果人们非要拿 C+和 Java 来作比较,我建议他们去阅读The Design and Evolution of C+,看看 C+为什么是今天这个样子,用我在设计C+时遵从的原则来检验这两种语言。这些原则与 SUN 的 Java 开发小组所持的理念显然是不同的。除了表面语法的相似性之外,C+与 Java 是截然不同的语言。在很多方面,Java 更像 Smalltalk(译者按:我学习 Java 时用的是 Sun 的培训教材,里面清楚地写道:

12、Java 在设计上采用了与 C+相似的语法,与 Smalltalk 相似的语义。所以可以说 Java 与 C+是貌合神离,与 Smalltalk 才是心有灵犀)。Java 语言相对简单,这部分是一种错觉,部分是因为这种语言还不完整。随着时间的推移,Java 在体积和复杂程度上都会大大增长。在体积上它会增长两到三倍,而且会出现一些实现相关的扩展或者库。这是一条每个成功的商业语言都必须走过的发展之路。随便分析一种你认为在很大范围内取得了成功的语言,我知道肯定是无有例外者,而且实际上这非常有道理。上边这段话是在 Java 1.1 推出之前写的。我确信 Java 需要类似模板的机制,并且需要增强对于固

13、有类型的支持。简单地说,就是为了基本的完整性也应该做这些工作。另外还需要做很多小的改动,大部分是扩展。1998 年秋,我从 James Gosling(Java 语言的创始人 译者)那里得到一份建议书,说是要在 Java 中增加固有类型、操作符重载以及数学计算支持。还有一篇论文,是数学分析领域的世界级大师,伯克利大学的 W. Kahan 教授所写的 How Javas Floating-Point Hurts Everyone Everywhere(“且看 Java 的浮点运算如何危害了普天下的芸芸众生”译者),揭露了 Java 的一些秘密。我发现在电视和出版物中关于 Java 的鼓吹是不准确

14、的,而且气势汹汹,让人讨厌。大肆叫嚣凡是非 Java 的代码都是垃圾,这是对程序员的侮辱;建议把所有的保留代码都用 Java 重写,这是丧心病狂,既不现实也不负责任。Sun 和他的追随者似乎觉得为了对付微软罪恶的“帝国时代”,就必须如此自吹自擂。但是侮辱和欺诈只会把那些喜欢使用不同编程语言的程序员逼到微软阵营里去。Java 并非平台无关,它本身就是平台。跟 Windows 一样,它也是一个专有的商业平台。也就是说,你可以为 Windows/Intel 编写代码,也可以为 Java/JVM 编写代码,在任何一种情况下,你都是在为一个属于某个公司的平台写代码,这些代码都是与该公司的商业利益扯在一起

15、的。当然你可以使用任何一种语言,结合操作系统的机制来编写可供 JVM 执行的程序,但是 JVM 之类的东西是强烈地偏向于Java 语言的。它一点也不像是通用的、公平的、语言中立的 VM/OS。私下里,我会坚持使用可移植的 C+作大部分工作,用不同的语言作余下的工作。(”Java is not platform-independent, it is the platform”,B. S 的这句评语对于 C+用户有着很大的影响,译者在国外的几个新闻组里看到,有些 C+高手甚至把这句话作为自己的签名档,以表明对 Java 的态度和誓死捍卫 C+的决心。实际上有很多程序员不光是把自己喜爱的语言当成一种

16、工具,更当成一种信仰。译者)11. 您怎么看待 C#语言?就 C#语言本身我没什么好说的。想让我相信这个世界还需要另外一个专有的语言可不是一件容易的事,而且这个语言还是专门针对某一个专有操作系统的,这就更让我难以接受。直截了当地说,我不是一个专有语言的痴迷者,而是一个开放的正式标准的拥护者。12. 在做大项目时,您是不是真的推荐 Ada,而不是 C+?当然不是。我不知道这是谁传出来的谣言,肯定是一个 Ada 信徒,要么是过分狂热,要么是不怀好意。13. 你愿不愿意将 C+与别的语言比较?抱歉,我不愿意。你可以在 The Design and Evolution of C+的介绍性文字里找到原因

17、。有不少书评家邀请我把 C+与其它的语言相比,我已经决定不做此类事情。在此我想重申一个我很久以来一直强调的观点:语言之间的比较没什么意义,更不公平。主流语言之间的合理比较要耗费很大的精力,多数人不会愿意付出这么大的代价。另外还需要在广泛的应用领域有充分经验,保持一种不偏不倚、客观独立的立场,有着公正无私的信念。我没时间,而且作为 C+的创造者,在公正无私这一点上我永远不会获得完全的信任。人们试图把各种语言拿来比较长短,有些现象我已经一次又一次地注意到,坦率地说我感到担忧。作者们尽力表现的公正无私,但是最终都是无可救药地偏向于某一种特定的应用程序,某一种特定的编程风格,或者某一种特定的程序员文化

18、。更糟的是,当某一种语言明显地比另一种语言更出名时,一些不易察觉的偷梁换柱就开始了:比较有名的语言中的缺陷被有意淡化,而且被拐弯抹角地加以掩饰;而同样的缺陷在不那么出名的语言里就被描述为致命硬伤。类似的,有关比较出名的语言的技术资料经常更新,而不太出名的语言的技术资料往往是几年以前的,试问这种比较有何公正性和意义可言?所以我对于 C+之外的语言的评论严格限制在一般性的特别特定的范畴里。换言之,我认为 C+是大多数人开发大部分应用程序时的最佳选择。14. 别人可是经常拿他们的语言与 C+比来比去,这让你感到不自在了吗?当这些比较不完整或者出于商业目的时,我确实感觉不爽。那些散布最广的比较性评论大

19、多是由某种语言,比方说 Z 语言的拥护者发表的,其目的是为了证明Z 比其它的语言好。由于 C+被广泛地使用,所以 C+通常成了黑名单上的头一个名字。通常,这类文章被夹在 Z 语言的供货商提供的产品之中,成了其市场竞争的一个手段。令人震惊的是,相当多的此类评论引用那些在开发 Z 语言的公司中工作的雇员的文章,而这些经不起考验文章无非是想证明 Z 是最好的。特别是在这些比较中确实有一些零零散散的事实,(所以更具欺骗性译者),毕竟没有一种语言在任何情况下都是最好的。C+当然不完美,不过请注意,特意选择出来的事实虽然好像正确,但有时是完全的误导。以后再看到语言比较方面的文章时,请留心是谁写的,他的表述

20、是不是以事实为依据,以公正为准绳,特别是评判的标准是不是对于所引述的每一种语言来说都公平合理。这可不容易做到。15. 在做小项目时,C 优于 C+吗?我认为非也。除了由于缺乏好的 C+编译器而导致的问题之外,我从没有看到哪个项目用 C 会比用 C+更合适。(不过现在 C+编译器导致的问题还是不可忽略的,当你看到同样功能的C+程序可执行代码体积比 C 大一倍而且速度慢得多时,会对此有所感触的。译者)以下内容来自 Visual C+ Developers Journal 主编 Elden Nelson 2000 年 3月对 B. S 的专访16. 如果您现在有机会从头设计 C+语言,您会做些什么不

21、同的事情?当然,你永远都不可能重新设计一种语言,那没有意义,而且任何一种语言都是它那个时代的产物。如果让我今天再设计一种语言,我仍然会综合考虑逻辑的优美、效率、通用性、实现的复杂程度和人们的喜好。要知道人们的习惯对于他们的喜好有着巨大的影响。现在,我会寻找一种简单得多的语法,我会把类型系统的冲突问题限制在很少的几种情况里,而且你能很容易的发现这些问题。这样就能够很容易的禁止不安全的操作。(B. S 的原则是:对于糟糕的代码,就算是不能完全禁止,至少也要让它大白于天下,而不是藏在阴暗的角落里暗箭伤人。C+实际上已经提供了这样的机制,例如如果你使用象 reinterpret_cast(pointe

22、r)这样的很明显是非常糟糕的表达式进行造型,别人会很容易地找到问题所在。只不过 C+仍然允许你使用传统的、C 风格的造型机制,而又有不少人一直使用这种老式的风格,所以才引来麻烦多多。B. S 的意思是说,要是现在能够禁止老式的风格该有多好!作为语言设计者的他,恐怕是没有这个机会了,但是作为语言使用者的我们,却还有很大的希望去改进自己的代码。何去何从,应该是我们深思的时候了。译者)我还会把核心语言的体积尽可能搞得小一些,包括类和模板的关键的抽象特性,而把很多其它的语言特性放在库里来解决。当然我也会保证核心语言足够的强大,使得那些库本身也足以用这个核心语言来产生。我可不希望标准库的创建需要用到什么

23、不属于该语言本身的神秘机制。另外我会让这个核心语言的定义更加精确。(有不少新的语言在建库时就使用了一些“不属于该语言本身的神秘机制”,比如VB 和 JAVA。从理论上讲,这是近乎无赖的行径,所以 B. S 不以为然。不过从实用出发倒也无伤大雅。译者)最重要的是,我会在该语言被广泛使用之前尽可能维持一个很长的酝酿期,这样我可以以其他人的反馈为基础进行改进。这可能是最困难的,因为一旦有什么东西是明显出色和有前途的,大家就会蜂拥而至的来使用它,此后作任何不兼容的修正都会是非常困难的。我相信这些思想与我当初设计 C+时的理念是非常类似的,同样也是这些思想指引着一二十年来 C+的不断演化。当然,我认为现

24、在还没有什么东西能让我觉得像是“完美的语言”。17. 您预期 C+做哪些增强,会不会删掉一些东西?很不幸,虽然有一些东西很应该扔掉,但恐怕很难真的删掉任何东西。第一个应该抛弃的东西就是 C 风格的造型机制和类型截断转换。就算不禁止,编译器的作者们至少也应该对这种行为给与强烈的警告。我希望能用类似 vector 的东西彻底取代数组,但这显然是不肯能的。不过如果程序员们能主动使用 vector 来代替数组,就会立刻受益匪浅。关键是你不必再使用 C+中最复杂难缠的技巧了,现在有优秀得多的替代方案。至于主要的特性,我没想去掉任何东西。特别是那些把 C+与 C 区别开来的主要特性恐怕没法风平浪静的被抛掉

25、。通常问这些问题的人是希望我挑出诸如多继承、异常、模板等机制来接受批判。所以在这我想大声讲清楚,我认为多继承机制对于静态类型语言实现继承性来说是必需的,异常机制是在大系统中对付错误的正确方法,模板机制是进行类型安全的、精致的和高效的程序设计的灵丹妙药。我们可以在小的细节上对于这些机制挑挑刺,但在大的方面,这些基本的概念都必须坚持。现在我们仍在学习标准 C+,也正在标准所提供的特性基础上发展出更新的、更有趣的编程技术。特别是人们刚刚开始使用 STL 和异常机制,还有很多高效强大的技术鲜为人知,所以大可不必急匆匆的跑去增加什么新的机制。我认为当前的重点是提供很多新的、比以前更加精致的、更有用的库,

26、这方面潜力巨大。例如,如果有一个能被广泛使用的、更精致的支持并发程序设计的库,那将是一大福音C 风格的线程库(例如 Pthread译者)实在不够好。我们也就可以与各种其他的系统,例如 SQL 以及不同的组件模型更好地契合起来。数值计算领域的人们在这方面好像已经走在了前面,类似像Blitz+、POOMA、MTL 之类的高效而精致的库的开发已经取得了非凡的成就。(译者在 Internet 上造访了 Blitz+和 POOMA 的主页,前者是一个高性能数学库,据称其性能与 Fortran 77 不相上下,同时又支持大量的 C+特性。我想凡是对于数值计算领域有所了解的人都知道这有多么伟大的意义。POO

27、MA 则是一个专门研究 C+并行数学算法的项目,它的前景更加不可限量。译者非常认同 B. S 的这个观念。译者)有了足够的经验之后,我们就能更好的决定应该对标准做些什么调整。18. 显然,这几年世界变了,正在走向一个以 Web 为中心、分布式计算为主流的时代。那么您觉得 C+还能维持其地位吗?程序员们可不可能把若干种专用语言(比如 Perl、Javascript)综合运用以彻底取代某一种通用语言?(C+就是这样的通用语言译者)为了配合新的计算模式,C+及其标准库应该做怎样的调整?从来没有哪一种语言能适合所有的工作,我恐怕以后也不会有。实际系统通常是用多种语言和工具构造起来的。C+只是想成为若干

28、语言和工具中的一个,当某些专用语言在其领域里特别突出时,它们可以与 C+互为补充。也就是说,我觉得如果大多数现在的专用语言能借助特定领域的 C+库共同工作的话,它们会表现得更出色。脚本语言通常导致难以维护的代码,而且也没有给程序的结构、可扩展性和可维护性的优化留下什么余地。我不敢肯定未来的代码是否真的会是以 Web 为中心的。就算是直接处理 Web的系统也主要是由处理本地资源,如 IP 连接之类的程序模块构成的。地理上的分布性以及服务器软件对于并发机制的高度依赖对于系统的建造者来说的确是个挑战。有些针对上述问题的库已经出现,也许我们将会看到它们最终得以标准化。当然,一些原操作和保证规则应该被加

29、到核心语言中以提供对这些库的更佳支持。总的来说,对于 Web 和网络,我们非常需要一个真正的系统/网络级的安全模型。指望 JavaScript 之类的脚本语言实现这个模型无异于白日做梦。注意,我也没说 C+提供了这个问题的解决方式。C+ 的重心是高效的访问系统资源,而不是反欺诈。19. 您看 C+未来的走向如何?在接下来的 10 年里它会衰落吗?或者是基本保持现在的形式?或者发展变化呈不同的形式?C+有着最美好的未来。用它你能写出伟大的代码。除了故意进行恶意欺诈,C+仍将是开发高性能、高复杂度系统的最好语言。据我所知,没有那种语言能在通用性、效率和精致三方面的统一上可与 C+相提并论。我没看到

30、 C+有衰落的征兆。在我能预见的未来里,它的用途还会不断增长。当然,在未来的十年里我们会看到一些变化,但不会像你想得那么显著。跟每一种语言一样,C+ 也会发展变化。 “语言专家们”要求改进的喧嚣声震耳欲聋,但是系统开发者们的基本请求是保持稳定。C+会改进,但是这些改进将主要是为了反映从实践中得来的经验教训,而不会是为了追风尚赶时髦。为了更高效地使用一些新的编程技术,比如通用编程技术,可能会增加一些小的特性。会有大量的库涌现,我预期会出现一种崭新的、更出色的库支持机制。我希望新的扩展主要集中在支持抽象方面的一般特性,而不是为支持某些特殊任务的特定机制。例如,“属性”这个概念是很有用的,但我不认为

31、在一种通用编程语言中有它的容身之地。用标准 C+的一组类可以很容易地支持这一概念。如果我们感觉那族类对于“属性”这一概念的支持不尽如人意,也不会立刻跑去在语言里增加属性机制,而是仔细考虑如何改进类和模板以帮助库设计人员尽可能接近“属性”这个概念。也许通过改进函数对象的机制能够给这个问题一个满意的答复。为了使 C+在接下来的十几年中保持灵活可变,很基本的一点就是不要让标准 C+赶什么学术或者商业的时髦。人们要求增加的特性中很大一部分通过使用现有的标准 C+开发新库的方式都可以实现。还有,事实上人们渴望得到的很多特性已经被包括在标准 C+中,并且被最新的编译器支持。对许多程序员来说,提高代码质量的

32、最佳途径不是追求什么语言扩展,而是好好地、慢慢地品味最新的C+技术书籍(可惜我们到目前为止连这种机会都没有译者)。20. 您怎么看待脚本语言的兴旺态势?特别是 Python,似乎提供了一种学习OO 技术的更简单的途径有些语言很不错。比如 Python,我很喜欢。但是我认为你从不同的语言中学到的 OO 技术是不完全相同的。当然,每一个专业的程序员都需要通晓几门语言,并且了解各种语言在编程和设计技术上的不同。在我看来,用脚本语言建造的系统与用 C+那样的通用语言建造的系统大不相同。从两类语言中学到的技术区别明显。在 OO 技术里也不存在什么通用部分对于各种系统的高效建造来说都是至关重要的。21.

33、有没有计划往标准 C+里增加一些新的特性以支持分布式计算?没有,我也不认为有这个必要。用更好的库就差不多能解决问题了。最多,为了支持这类的库,我们可能会增加一些低级的原操作和规则22. 未来 C+有没有可能定一个可移植的二进制接口?如果你说的“可移植”是指跨硬件和块操作系统的可移植,我想回答是不会。我们当然可以设计一个解释器或者虚拟机(如同 Java 的做法译者),但这样一来,由于无法以最优的方式访问系统资源,C+的能力就会受到削弱,。我真正希望在不远的将来能够看见的东西是 platform ABIs。例如,有人正在努力为 Intel新的 IA64 体系定义 C+ ABI,我想这些努力会得到用

34、户们的巨大支持。能够把不同编译器产生的代码编译在一起将会是一项十分有意义的事情。23. 在不少流行领域,C+正在渐渐失去光芒,因为它要求人们花很大的精力去对付一些很基本的工作,比如管理内存(因为没有垃圾收集机制),管理模块之间的依赖性(因为没有包机制),管理组件的版本。C+缺乏一些现代语言已经视为标准的特性。比如传言中最酷的 Java 语言就特别重视这些问题。那么在解决这些问题是否会导致 C+的发展背离其根本宗旨呢?C+ 应该怎样发展以保证我们在这种语言上的投资能有合理的回报,而不是被迫去重新使用另一种语言?我倒还没有注意到 C+比以前用的少了。相反,我看到的指标表明 C+的使用还在稳定地增长

35、着。只不过这种基数很大的稳定增长以及在标准性、移植性和库方面的不断提高并没有造成什么具有欺骗性的新闻效应而已。我认为你所说的“失去光芒”只不过是市场推销和新闻意义上的现象。如果你需要垃圾收集机制的话,你可以在 C+应用程序中插入一个垃圾收集器。有不少自由的和商业的垃圾收集器已经在重要的实践中被证明是很出色的。如果你不想使用垃圾收集机制,也没关系。你可以使用标准容器类,它们大大减少了对于显式分配和回收内存的需要。这样,使用现代的库和现代的编程风格,你能够避免大部分的内存管理问题。同样的技术还能够用来避免一般资源的管理问题。并不是只有内存才会泄漏,线程句柄、文件、互斥锁、网络连接等都是重要的资源,

36、为了建立可靠的系统,这些资源必须被正确的管理。如果你觉得有了垃圾收集机制就可以解决所有的资源管理问题,那么你最好赶快从美梦中醒来。C+提供了很多机制来管理一般性的资源。关键的手段“获取资源就是初始化”可以使用函数对象来管理生存期问题。语言中关于对象的局部构造和异常机制对这项技术提供了支持。某些语言的狂热支持者总是用讽刺漫画的笔法描述 C+,然而 C+实际上要好得多。特别是我觉得很多其他的特性已经泛滥不堪了,在 C+中,通常这些特性能够很容易的被模拟出来。相反的,新的语言在推广的过程中总是不断地增加新的特性,这就是为什么从一种语言诞生到被广泛使用,其体积通常会增加个两三倍。目前,最为个人和组织,

37、对于 C+的最好投资就是去更好地理解标准 C+和现代的 C+设计编程技术。大多数人使用 C+的方式实际上停留 80 年代中期的水平,甚至比那更陈旧。至于模块依赖性问题,我的观点是,在编程语言的工作和系统的工作之间应该有一个明显的界线,依赖关系应该尽可能地与编程语言分开,而由系统来支持。我不认为组建版本的问题应该由编程语言来解决,这是一个系统范畴里的问题,在语言里应该通过提供相应的库来解决。C+有这样的机制。解决这样的问题不会使 C+偏离轨道。但是给 C+增加很多特殊的特性就会使 C+偏离轨道,而且在保持可移植性和平台独立性方面也会是一个倒退。24. 标准 C+推出有段时间了, Java 也大踏

38、步地往前走而且取得了显著的进步,您现在怎么比较 Java 与 C+?您觉得 Java 想要变成像 C+一样“好”的语言还需要做些什么?您举的 C+从 Java 身上学到了什么经验吗?有没有什么 Java 的特性您认为是可以被 C+吸纳的?我不比较语言。做好这项工作是十分困难的,而且很少具有专业水准。我认为 C+的进步会是主要以它的用户在使用中遇到的问题以及其自身逻辑为基础。当然,其他语言中的某些思想也会被考虑,但不能被简单的移花接木过来。你必须审视那些机制在技术上和思想上的背景,并且找到在 C+中支持这些技术的最佳方案。有时最好的选择是综合使用几种语言。毕竟没有任何一种语言是放之四海而皆优的。

39、C+现在是,将来也继续会是在广泛应用领域中最好的语言之一。但是,我们不能被拉下水,不能把所有可能的特性都加到 C+里面来向大众献媚。我认为Java 和 C+现在和将来都会是十分不同的语言,语法相似,但背后的对象模型明显不同。对于我来说,一个很重要的区别是 C+有一个 ISO 标准,而 Java 则是一个专有语言。25. 在 Java 刚刚出现的那几年,有很多欺骗性的言论说它将会是终极语言,会取代 C+。您觉得在过去两三年里 Java 对 C+的追随者们有什么影响?到现在关于 Java 的不实之辞也还随处可见。暂且不提 Java 在过去 5 年间的创纪录的发展,狂热的大众似乎认为 Java 将最

40、终取代的不仅仅是 C+,而且还有所有其他的编程语言。但在另一方面,C+的使用仍在继续增长。我不认为 Java 对于 C+的影响已经使得人们转而把本来打算用来创造更好的 C+工具库的资源调过去开发 Java 工具库。Java 对于学习编程的人来说没有太多的新东西,所以对于C+的定义也没什么影响。在那个领域,Java 还得努力追赶。例如,我认为为Sun 迟早会往 Java 里加入类似模板的机制。人们应该认识到 C+和 Java 的目标是何等的不同。 以 C+的设计理念来衡量Java,或是以 Java 的设计理念来衡量 C+,得出的结论都不会很好。在访谈即将结束时,或许我该再次表明态度:C+仍然是我

41、喜爱的语言,在写代码时你会发现没有那种语言能像它那样在如此广泛的应用领域和平台上同时达成如此的高效与精致。Bjarne Stroustrup 语录一、致读者1 在编程序时,你是在为你针对某个问题的解决方案中的思想建立起一种具体表示。让程序的结构尽可能地直接反映这些思想:.如果你能把“它”看成一个独立的概念,就把它做成一个类。.如果你能把“它”看成一个独立的实体,就把它做成某个类的一个对象。.如果两个类有共同的界面,将此界面做成一个抽象类。.如果两个类的实现有某些显著的共同东西,将这些共性做成一个基类。.如果一个类是一种对象的容器,将它做成一个模板。.如果一个函数实现对某容器的一个算法,将它做成

42、为对一族容器可用的模板函数。.如果一组类、模板等相互之间有逻辑联系,将它们放进一个名字空间里。2 在你定义一个并不是实现某个像矩阵或复数这样的数学对象的类时,或者定义一个低层的类型如链接表的时候:.不要使用全局数据(使用成员)。.不要使用全局函数。.不要使用公用数据成员。.不要使用友元,除非为了避免 a 或 c。.不要在一个类里面放“类型域”(指那种为了说明一个类所存储数据的情况而放置的标志域) ;采用虚函数。.不要使用在线函数(inline function),除非作为效果显著的优化。二、C+ 概览1 不用害怕,一切都会随着时间的推移而逐渐明朗起来。2 你并不需要在知道了 C+的所有细节之后

43、才能写出好的 C+程序。3 请特别关注程序设计技术,而不是各种语言特征。三、标准库概览1 不要像重新发明车轮那样企图做每件事;去使用库。2 不要相信奇迹;要理解你的库能做什么,它们如何做,它们做时需要多大的代价。3 当你遇到一个选择时,应该优先选择标准库而不是其他的库。4 不要认为标准库对于任何事情都是最理想的。5 切记#include 你所用到的功能的头文件。6 记住,标准库的功能定义在名字空间 std 之中。7 请用 string,而不是 char*。8 如果怀疑,就用一个检查区间范围的向量(例如 Vec)。9 vector 、list和 map 都比 T 好。10 如果向一个容器中添加一

44、个元素,用 push_back() 或 back_inserter() 。11 采用对 vector 的 push_back(),而不是对数组的 realloc()。12 在 main()中捕捉公共的异常。四、类型和声明1 保持较小的作用域。2 不要在一个作用域和它外围的作用域里采用同样的名字。3 在一个声明中只声明一个名字。4 让常用的和局部的名字比较短,让不常用的和全局的名字比较长。5 避免看起来类似的名字。6 维持某种统一的命名风格。7 仔细选择名字,反映其意义而不是反映实现方式。8 如果所用的内部类型表示某种可能变化的值,请用 typedef 为它定义一个有意义的名字。9 用 type

45、def 为类型定义同义词,用枚举或类去定义新类型。10 切记每个声明中都必须描述一个类型(没有“隐式的 int”)。11 避免有关字符数值的不必要假设。12 避免有关整数大小的不必要假设。13 避免有关浮点类型表示范围的不必要假设。14 优先使用普通的 int 而不是 short int 或者 long int。15 优先使用 double 而不是 float 或者 long double。16 优先使用普通的 char 而不是 signed char 或者 unsigned char。17 避免做出有关对象大小的不必要假设。18 避免无符号算术。19 应该带着疑问去看待从 signed 到

46、unsigned ,或者从 unsigned 到 signed 的转换。20 应该带着疑问去看待从浮点到整型的转换。21 应该带着疑问去看待向较小类型的转换,如将 int 转换到 char。五、忠告1 避免非平凡的指针算术。2 当心,不要超出数组的界线去写。3 尽量使用 0 而不是 NULL。4 尽量使用 vector 和 valarray ,而不是内部(C 风格)的数组。5 尽量使用 string 而不是以 0 结尾的 char 数组。6 尽量少用普通的引用参数。7 避免 void* ,除了在某些底层代码里。8 避免在代码中使用非平凡的文字量(“神秘的数”)。相反,应该定义和使用各种符号常量

47、。(这里应理解为避免使用无意义的立即数,而定义一些能够代表意义的常量,例如,用 true 而不要用 1(C/C+)或-1(VB )学习 c+应该看的书(C+学习的四个层次)层级一:语法/语意(C+)Lippman2000 Essential C+ 推荐Essential C+,by Stanley B. Lippman Addison Wesley Longman 2000,276 pagesEssential C+ 中文版 ,侯俊杰 译,282 页Gregory95 C+:The Core LanguageC+:The Core Language by Gregory Satir 1995

48、OReillyC+语言核心,张铭泽 译 ,236 页Deitel98 The Complete C+ Training CourseThe Complete C+ Training Course 2/e by Harvey M.Deitel 1998 Prentice HallC+大学教程 (第二版),邱仲潘等 译,816 页Stevens2000 Standard C+ BibleStandard C+ Bible 2000 Al Stevens IDG标准 C+宝典,林丽闽等 译,766 页Eckel2000 Thinking in C+ 第二版翻译不大好,建议看原版 Thinking in C+ 2/e Bruce Eckel 2000 1470 pages Prentice HallC+ 编程思想,刘宗田等 译,420 页Lippman98 C+Primer 有点 C+基础再看,强烈推荐! C+ Primer,3rd Editoin,by Stanley Lippman and Josee LajoieAddison Wesley Longman,1998 1237 pagesC+ Primer 中文版,侯俊杰 译,1999,1237 页Struostrup2000 专家级,需要一定水平The C+ Programming Language,Sp

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 企业管理 > 管理学资料

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报