« Effective C++ 3rd Edition | 返回首页 | QQ 用户关系的迁移 »

Effective C++ 3rd 的一点评论

今天终于把作业作完了(可能还有地方要返工),Effective C++ 第 3 版读完了,写了几万字的评论。如我给编辑交稿的 email 里所写:

我觉得评注这个工作比翻译难做。作者细节上讲的非常清楚,大部分地方都不觉得有必要再加注解。我想跟这本书反复写了 10 年有关。所以很多页我都没留评注,真的不知道可以写啥。

编辑原想每页中英分列排版,我是不建议这样的。除了少部分评注,针对个别代码段,或关键词。大部分我的文字都是独立成段的。跟具体原文句子关系不大,只跟篇章段落主题有些许联系。

前几天跟孟岩兄 email 交流,我发了一些稿子给他。他觉得关于本书第一篇 Item 1 : View C++ as a federation of languages ,我的评注还是没有讲透。是的,许多观点还是很难表达清楚。

下面选一段贴出来吧。

Item1 / P11

无人能掌握 C++ 所有的枝节。这并非夸张的说法,也不是藐视读者的智商。因为 C++ 本身就不断在发展,不断的加入新的东西。

很多年之前,我学习 C++ 时用的第一个 C++ 编译器 (Turbo C++ 1.0) 中,template 还只是一个被保留而未被实现任何功能的关键字。就是这个不起眼的小玩意,即使是 C++ 之父,一开始也未能意识到其中蕴涵的巨大能量。可它在 C++ 诞生的若干年后,居然成为了 STL 的基石。

Item1 / P12

C++ 不是绝对意义上的 C++ 。在本书的第二版中没有 Item 1 这一节,而在这一版中,把这一大段放在了第一条,可见作者对这个问题也是逐步认识的。我对此深以为然。这一篇是全书的中心,读此书必须先细细品味它。如果之前读过第二版,对比一下行文风格,就能发现有极大差异。作者不再强调在 C++ 中必须怎样做,文字中隐隐透着些许无奈,本篇是最佳注脚。

在我看来,C++ 各个不同的方面的差异性要远大于它们的共性。C++ 经过几十年发展逐渐演变成今天这样,将如此之多的编程风格糅合在同一门语言中,让它们能和谐共存,是非常困难的事情。它尽可能的去满足各种项目,各种人在各种时期的不同需求。它不是在一开始经过深思熟虑定义出来的。C++ 语言发展到今天,还能发展下去,难能可贵。C++ 新标准从 1998 年到现在,十多年过去了,还未能完全定稿,真的很容易理解。

在某些 C++ 教材上,反复强调不要把 C++ 当成 C 使用(包括本书第二版)。在某种意义上说没错。但只使用 C++ 的一部分:只是 C 的部分,仅仅利用 C++ 的改进来弥补 C 的一些缺陷,在工程实践中也是个不错的方案。如何使用 C++ 最好,仅取决于你的开发团队怎样定义你们使用的 C++ ,并且是否全部认同。Google 在这一点上做的很好,在网络上流传着 google 发布的 C++ 编码规范。有规范、且大家一起遵守之,比到底规范了些什么重要的多。

我在 2005 到 2006 年间,曾经在团队中推广过一段时间类似 C 的 C++ 子集做开发,那和我早些年编写的 C++ 程序风格完全不同,也工作良好。不过这段经历最终使我对面向对象和模板技术做了许多反思,并最终转向彻底的纯 C 开发。

我个人觉得,应该多尝试一些不同的东西,而不要武断的把任何技术当成唯一真理。你可以热爱面向对象,也可以尝试一下 Template 。但需要警惕的是,C++ 虽允许你把各种不同风格的编程方式揉杂在一起使用。每种都提供了高性能的支持。可以取各家之所长,有种世界在我手中的感觉。甚至可以在 C++ 程序员中不断制造出创新的快感。殊不知,其引起的冲突和复杂性,可以轻易超过个人能控制的范畴。仅仅是语言的学习,而不经过长年的经验积累,是很难有切身体会的。尤其是对于聪明之如 C++ 程序员,更是危险。

Item1 / P13

定义你想怎么使用 C++ 非常重要。这决定了你的项目是否能够长时间做下去直到发布。即使你只有一个人,你也会使用别人的代码(至少是标准库),或是提供扩展接口供别人编写扩展。这都会和并非出自你手的代码打交道。即使是所有的一切都是一个人掌握,也不可能随心所欲的使用那些 C++ 中看起来最酷的特性。因为你总会发现 C++ 中还有更有趣的东西能够挖掘。逐渐的,项目会偏离原始的目标,编写 C++ 代码只是为了用 C++ 编写,而非为了解决问题。

Comments

这太酷了。我喜欢你如何把这个页面一起。你做了出色的工作。祝好运。
看了C++沉思录感觉要想用好用活C++,必须改变自己对编程这个工作的看法,改变解决问题的思维方式,C++的灵魂就是抽象,就像指针是C的灵魂一样,编写代码来解决问题之前先把问题用面向对象技术建模,然后抽象,并考虑怎么用C++特性来表达,感觉跟描述型编程语言相像,比如PROLOG,它们的方法就是先把问题用这个语言的语法描述出来,包括解决问题的方法一起用语言描述出来,编码只是最后的工作而已
以前总是以可以用PASCAL和BASIC自居,在DELPHI的世界里游荡了许久,沉迷于VCL的世界,藐视过MFC,现在呢VCL差不多已死,MFC一家独大,郁闷啊,而对于C++可以说是因为PASCAL而失之交臂了,当时不知看了哪个枪手的文章鼓吹PASCAL的优越性而放弃了继续学习C++的决心,以为会点C就足够了,C++能做的PASCAL一样做得好,现在看来纯粹狗屁,唉,没办法,重头再来学C++吧...
坚持c++的道路
不错,有用,谢谢分享
以前学C++的时候,觉得这是一门高级语言,那时候还是很佩服玩汇编这种NB的。可是现在,在接触了一些更高级的JavaC#和一些web的编程语言后,发现,C++已经变成NB语言了。 以前总是觉得C++没有用好,只是用类来帮我组织程序结构,总是没有用好继承,所以就没有成就感。后来发现一些C++和Java的高手说面向对象中的继承是用处不太大的,主要是范式等,突然释然了一下。不过,我这里垮平台太多,win和linux里面的C++线程函数不一样,确实很烦。
楼了 偶像
我来凑凑人数。。。多我一个不多吧??
c++的const 关键字 和 类型转换保护 这两点无论如何对于c是巨大的进步和优越性。其他复杂的特性确实容易迷惑,不过你可以不用。要让我返回c那是很难接受。最理想是弄一个c++精简版,就留最常用的c++特性。云风大大应该可以试试。
面向对象是一种工程构建的方法和具体的语言无关,妄图用语言的面向对象来构建工程的想法出发点就注定了C++这条路并不好走。说的通俗点是把无限的变化投入到语言有限的语法中,小应用的工程还能忍受并且看起来代码还规范很多,大的工程就会让人抓狂。 非常同意 c++是一门学院派语言,说白了,就是作者和几个人在一起,创出来的一门类似simula的c语言,加上妄想一门语言可以完成实际问题域的建模(类,OO,模板),殊不知实际世界关系是如此的复杂,怎么能让你一门语言这么简单的就可以抽象模拟出来出来。 更有一部分,只见树木不见森另的语法元素,例如运算符重载,为了区区几个操作符可以在自定义类型上使用,就引入那么多语法,实际上操作符重载根本就毫无意义。实际的类型其接口多样化,根本不是操作符可以描叙的。 所以,选择一门简约的语言(不那么有野心),使用平凡的心态去学习、使用,精心的设计、编码、测试才是符合项目的发展的之道。
面向对象是一种工程构建的方法和具体的语言无关,妄图用语言的面向对象来构建工程的想法出发点就注定了C++这条路并不好走。说的通俗点是把无限的变化投入到语言有限的语法中,小应用的工程还能忍受并且看起来代码还规范很多,大的工程就会让人抓狂。
大部分观点还是认同的。我在用C++的时候也是“把着用”。就是收敛着用。但还是在努力地学习它。不是为了能拿出来炫耀,而是不想“在阴沟里帆船”。 现在的语言,都是非常庞大的,学哪个都一样。既然会点C,那就接着学C++吧。
工作3年一直用C++,我也发觉特性太庞杂,特别是模板有些特性还没标准化,一直在发展,开发还要背负许多智力包袱。如果要用,可以以批判的态度来用C++,约束的来用C++。我也想考虑把项目带入C。
工作3年一直用C++,我也发觉特性太庞杂,特别是模板有些特性还没标准化,一直在发展,开发还要背负许多智力包袱。如果要用,可以以批判的态度来用C++,约束的来用C++。我也想考虑把项目带入C。
C++ 不是绝对意义上的 C++ 。很玄乎,很有古龙的味道
翔子也来学习了 希望博主有时间到我那里做做!
尺有所短,寸有所长。 语法糖甜,语法糖苦。
曾经弄懂过, 很快就又忘记了....
c++也用了5年多了,一直感觉用得不是很顺手,我一直以为是我个人的问题,比较笨吧?好在2年发现了不仅仅是我会有这样的问题,别人也是,也就坦然了,c++中充满太多的意外,经常给你“惊喜”,现在对于c++,我也就是批判的用用着他了,不会花太多精力去搞花哨的角落技术,对于现成的库,我拿来用即可(不钻研),例如QT,核心我是采用C来编写,或者C风格来写作,c++的思想包袱过重,给人束缚。 话说window平台上面的开发我个人觉得window API + c挺好的,开发速度是满了点(玩具程序),但是对于真正的产品开发来说,这点估计不是什么问题吧?好像云风他们开发程序,连CRT都自己写了呢
用C++确实有一种世界在我手的感觉。特别在看SGI STL和Boost源代码的时候。 不过云老大说的尝试多种语言, 我尝试了python, 虽然语言特性确实优雅,简单,但是却没有像C++让我成为起死忠的感觉。
用C++确实有一种世界在我手的感觉。特别在看SGI STL和Boost源代码的时候。 不过云老大说的尝试多种语言, 我尝试了python, 虽然语言特性确实优雅,简单,但是却没有像C++让我成为起死忠的感觉。
哦!之前在VC中用纯C编译调用DirectX的经历时被引入误区了呢,加上DirectX用起来像用C++类成员函数,我被表象迷惑了。 市面上很多c++讲解的书籍,个人感觉看一大堆那些c++特性的讲解,还不如直接写一段程序看其对应的汇编代码来得深刻。不过看云风的评注甚觉很精彩,是书中难得的亮点,很好看
个人观点: 对于C语言开发,半年时间就能把人培养成代码机器,没有太多的个性,无论从命名规范还是多线程并发。有点像打台球或者弹钢琴,熟能生巧,靠的是耐心。 而对于C++来说,每个人写出来的风格都不同,根本原因还是每个人对C++的理解不同。有点像下围棋,段位能分出九等。看自己以前写的C++代码,会哭笑不得;而看高手写的代码,则是一种享受(不是因为负责的技巧,而是因为条理清晰)。 不断提高对C++的理解,多少会有一点成就感,而成就感对于程序员也许就是一切。
DirectX 是基于 COM 的,无所谓 C 还是 C++
呵呵,云风最近一直用纯C啊!话说MS的DirectX就是C++封装的。 在VC中用纯C无法直接调用DirectX函数,似乎只能每个函数得重新声明函数指针才可调用DirectX函数,真是超麻烦啊! 就开发Windows游戏而言,个人更偏向喜欢OpenGL接口,可惜支持OpenGL驱动的显卡没有DirectX的显卡多
看不太懂程序。嗯,不过能够理解那种发掘的快乐。虽然褒义看起来比上一篇日志多了一些,大概要落成铅字的东西,总会更慎重。
膜拜云大大
写的不错,基本上所列的这些观点我都认同。 1、C++的非常复杂的,不要试图去全部弄懂它,即使今天你以为全部弄懂了,明天还会有新的东西加进来。 2、定义你想怎么使用 C++,并且只使用 C++ 的一部分:比如仅仅利用 C++ 的改进来弥补 C 的一些缺陷,在工程实践中也是个不错的方案。 3、不要随意的去滥用C++的各种复杂特性,因为其引起的冲突和复杂性,可以轻易超过个人能控制的范畴。 4、永远记住在项目中用C++是为了解决问题,而不是为了炫耀技巧,或者别的什么原因而为了用C++而用C++。 如果坚持这些原则的话用好C++应该是没有问题的,所以其实我一直没搞明白云风放弃C++而改用C的理由。
是你让我决定买了《c programming language》细读一遍。表示感谢。
我来占楼了 偶像
云风大虾的沙发,哈哈。

Post a comment

非这个主题相关的留言请到:留言本