« 新西兰南岛游 | 返回首页 | Effective C++ 3rd 的一点评论 »

Effective C++ 3rd Edition

最近一个多月的业余时间都耗在了《Effective C++ 3rd Edition》这本书上。读的很辛苦,不仅仅是因为这是本英文书。之前答应了博文的编辑帮这本书写评注,将来用于出版。对于要印成白纸黑字的文章,不得不谨慎一些。

我已经有 4 年没有大段时间写 C++ 代码了。中间偶尔有几天写过几千行,其余的 C++ 经验就来至于 google reader 上的阅读。为了读这本书,我又重温了《C++语言的设计和演化》的几个章节。不过整个阅读过程还是不太赏心悦目。

可能还是因为我对 C++ 偏见过多,有如前几年对其的推崇备至。总觉得书里讲的太细,太多观点本是好的,只是局限在了 C++ 语言中。明明是 C++ 的缺陷,却让人绞尽心力的回避那些问题,或是以 C++ 独特的方式回避。在别的语言中不该存在的问题,却成了 C++ 程序员必备的知识。人生苦短,何苦制造问题来解决之。

可这也正映射了本书的主题:有效使用 C++ 。读下去,感觉能懂 Scott Meyers 了。我不相信大牛如厮,写了 10 多年一本书,就没有抱怨的。昨夜,读到 Item 25 ,关于对 std::swap 的扩展问题。109 页引申到特例化 std 名字空间里的方法时。一句“Alas, the form of the prohibition may dismay you” 尽显无奈。

我是上个月初去广州开会的旅途上开读这本书的。当时飞机晚点,在机场耽搁了四个小时。随身带的就这本书和一支铅笔。连同空中的时间,一共六小时。在书上做了几千字的记录。后来在新西兰,晚上边读边记。磨磨蹭蹭的读了几十页。当是把书越读越厚了。

如果不是为了完成先前百般推脱的这个任务,想来是不会这么有耐心的逐字读那些英文句子的。读的越细越发现没啥好评注的。要以我近年对 C++ 的态度。每篇只读个标题,估计就草草翻过了。都是 C++ 程序员必备的知识,还翻来覆去的讲个没完。剩下那些语法细节,属于语言工具相关的知识,不做 C++ 程序员本不必学习了。没太大启发。

结果,评注下来大部分都是对 C++ 的争议。稿子发给编辑看了。说是缺少一些对“初学者解惑和提速”的部分,而“批判固然是好的”,但比例也太大了。而且大部分页面空空,没落任何文字。

我也认为,无论怎样写下文章,都带有现实的局限性。或许过两年想法就变了。但文字印刷出来,就无法更改。如果有多余的精力,可能最后再来过一遍吧。想在出版时加上一篇免责声明,不要因我言论误导,而放弃学习 C++ 。希望不要因为我的评注,影响了书的销量 :)

btw. 如果仔细对比这本书的第二版(我前些年就是读的第二版,侯捷的中译本)和第三版,就会发现这简直是一本新书。

Comments

https://www.csdn.net/article/2012-08-20/2808822-GCC-uses-cpp-to-compile

连gcc都改用c++写了。
做应用永远都不应该用c

第三版没看过,第二版那些条款全废了?!

近些年应该有不少大规模使用C的经验了,其实分享一下更好

我觉得不应该有这么先入为主的观念啊,C++自然有它存在的道理~~~
Effective C++ 还是很经典的,如何举一反三 才是读者的高尚境界

语言不应该成为一个程序员的标志。思想才重要。

小生可能愚笨。。不过effective c++第三版(对,我不是说第二版)好像也早就由侯捷先生翻译了吧。。。

冬天到了,于是看的几个博客都不在更了。杭州要降温,注意保暖。

膜拜云大大

看过2, 3也要出来了啊, 云风从推崇c++到批判c++, 而现在推崇c就是因为简介一个原因吗?

晕疯居然还能读懂英文版的书。。。。

真正的程序员应该超越于代码之上。

"它告诉程序员,该怎么写,才可以避开陷阱。"
这本身就是一种trick.

Effective C++ 这本书不是写 trick 的。甚至可以说是一本反 (trick) C++ 的书。它告诉程序员,该怎么写,才可以避开陷阱。

我不觉得语言本身有什么问题。喜欢用,能用好就行了。再好的语言,你用的不好、解决不了问题,也是白瞎。
至于学习成本问题,不同的人的经历不同,思维方式不同,学习成本也就不一样了。与语言关系不大。

国内软件技术出版市场应该减少这种语言trick的书籍, 增加各个领域应用设计的书籍。
市面上充满了各种编程语言的书籍,对众多fresh的技术人员绝对是一种误导。

to myan:
你回错楼层啦~

to 赵中:
不要误解我的意思,其实我的结论是,C++是一种好语言,只是你要用对,避免如云风所说的自己找来的麻烦。
还有,你对我的建议是不对的,一个对象先被销毁了,就不能再调用“判断”这个方法了。

感觉任何语言都不可能满足所有人类的需求,正所谓萝卜白菜更有所爱。重要的还是要学会使用它去解决实际的问题,这就达到了基本的目的

做个可能不太恰当的比喻:
人想让狗帮忙逮只兔子,可是人说话狗听不懂,于是人发明了一种介乎人言和狗语之间的语言,即口令。
人想让电脑帮忙做计算,可是人话电脑听不懂,于是人发明了一种介乎人言和汇编机器码之间的语言,即C语言。
人对狗的口令得让人容易学、也得让狗容易懂。
C语言同样得让人容易学、也得让电脑容易懂。
相比之下C++、Java就是人学得费劲、电脑也经常闹不懂。

to myan:
c++是不是历史性的错误评价还早,等自已成为历史之后再做判断比较合适:)

支持下

之前我也多次怀疑C++整个就是个历史错误,但是都担心其实是自己的局限。后来梳理了C++ delegate 的发展过程之后,并且研究了现在还算成功的Qt之后,对于C++的历史定位比较明确了。你可以相信自己对于的看法并非偏见。

我看过google的c++编程规范http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
,禁用了很多东西(异常等),个人觉得如果把编译器相关的,或者太复杂的东西都禁用掉,c++还是挺整洁的。

"其余的 C++ 经验就来至于 google reader 上的阅读",云风大哥能否分享下

在msdn中查看一个主题时(win socket),主题的内容都是类似的:
1:关于win socket
2:using win socket
3: win socket functions
4: win socket struct

我相信,大多数程序员都喜欢看这种c风格的api帮助文档,而不是mfc的那种充满对象味道的api帮助文档。

单从文档对比来看,c++的学习成本就比c高多了。 c带给程序员的就是简单,清晰。

保持学习。

云风近些年应该有不少大规模使用C的经验了,其实分享一下更好

云风的blog一直在跟,收获颇丰,作为一个老程序菜鸟,一直认为c++是在谋杀程序员的宝贵时间,其实不应该作为主流语言推广的,但是很多的大牛却又偏偏喜欢将c++反复炒作,好像不会c++,就不能做出成功的项目一样。
好在这几年,对c++的批判终于成为主流了。
c++不能减少任何问题域的复杂度,反而引入了语言工具的复杂度,纠缠在一起,项目就只好延期了...

如果不喜欢C++或是觉得C++有很多缺陷何必还要写,让人再误入其途呢?不是很多人都能像你一样恰当的放弃一种习惯。

第三版也有侯捷译的啊,为什么还要再译?

C++在GUI和游戏领域还活着,剩下的公司里还在用的只有老的COM组件和ActiveX控件了

偶像啊

Post a comment

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