有点失望

2010-01-23 06:20:48   来自: Milo
0 bug的评论   2 star rating2 star rating   2


  (因為本評論的一些回覆沒有了,可能會做成一些誤會,原文請參考 http://www.douban.com/review/2963028/ )
  
  看到这本书的题目,既猜疑又好奇,作者有什么好方法去写无错误的软件呢?
  
  可是收到本书后,越看越觉得不对劲。本人才疏学浅,评论不对的地方希望作者不要介意。我第一次写这么长的书评。
  
  首先,本书内容中有大量错误的地方需要纠正。因为错误(不是错别字等小错误)实在太多,阅读时也没有一一记下来,只随便找些例子:
  
  - P.41 「CPU每个时钟周期,至少能通过总线访问到1个字节」是不对的。如果是这样,就不用L1、L2 Cache了。整个2.3.1是要说明为什么要使用锁,但这段说明是错误的。
  
  - P.45 整页说明Windows 加锁有漏洞、不严谨。文中没说是那种"锁",估计是Mutex。 Windows的Mutex是recursive的, Linux 预设的是non-recursive,但也可以使用recursive mutex的。这应该不是Windows的错而是作者的错。
  
  - P. 86 「由于C 和C++ 语言,标签在编译时一般都具有全局性,因此,一定不能重名......」标签只需要在一函数内不重名就可以,goto 也只可以使用同一函数里的标签。那种全域命名方式是没需要的。
  
  - P.91, 127 说ternary operator (即a ? b : c) 没用,用if-else 可以原全取代。这是 expression 和 statement 的分别。例如你不可以用if-else 写一个MAX(a, b) 的宏。
  
  - P.102 作者说类只使用public 和private,不知道为什么要有protected,说看不出protected和friend的用途,所以建议大家不要用。这两个关键词都在类的封装中有重要及无法替代的用途,建议作者看相关书籍。
  
  - P.102 第2段「用聚合不用重载」,但从内文推理作者应该是指不要用承继(inheritance)。
  
  - P.109-P.111 对C++物件模型的错误解释。那个物件的「函数指针表」是不存在的。有虚函数的类才需要每个物件多出一个虚函数表指针,指向一个类的虚函数表。另外为解决内存碎片问题,C++物件中应该用placement new、new operator重载或/和显式解构。
  
  - P.118-119 对头文件依赖问题错误描述。 Forward declaration 只能声明一个型别的存在,所以只能使用其型别的pointer或reference,而在例子中用A a是不行的。一个header #inlclude 另一个header是很正常的做法。
  
  - P.126 说不需要用 ++i 只需要用 i++。在C++ 里是建议相反的,因为物件的post increment/decrement operator是需要额外的copy construction。
  
  - 书中很多string/buffer 长度、sizeof() 的结果等,都使用int 型别。正确的型别应该是size_t。
  
  我还只读到第3章「C/C++无错化程序设计」,也不知道能否阅读下去,就先写一些读到这里的感想:
  
  - 作者不断说自己有十多年C商用开发经验、十年C++开发经验,但好像对C/C++的知识有点不足,尤其是C++。
  
  - 前三章举出很多笔者的经历。我看过颇多的技术性书籍,但比较少看到这种描述:「笔者一个月左右完成......仅仅查出1个bug。获得公司和同事的好评。笔者近期带领团队开发. .....bug只有7个。也获得了公司的肯定」、笔者怎样用两天解决了另一个同事做了两个月的事情。
  
  - 书名比较言过其实。作者提到自己做的案例也不是0 bug......
  
  - 书中的用字不够严谨,而有些是笔者惯用或创造的词语。建议用比较正规、并前后一致的词语。
  
  - 书中很多内容都是作者的经验分享,并介绍作者开发/设计(文中经常用"发明")的一些工程库。但书中好像没有比较或参考相关的演算法(如lock-free algorithms)或程序库(如ACE、TBB等)。个人会怀疑这些是否「重发明轮子」,还是因为一些特殊的需求而订制的。
  
  如果是要看如何可以减少编写(C/C++)代码的错误,我会比较建议看《代码大全》、Scott Meyers的Effective系列。
  
  最后,我还是支持作者分享原创的心得。希望作者在续版及新作能更进步。
你认为这篇评论: 175 2

2010-01-25 19:09:47 Milo

  多謝肖先生回覆。 我是在當當買的,只看過評語就買了, 說實話有點後悔。
  
  我絕對沒有「駡」作者的意思,只是實事求事,把我看到的問題說出來。我雖然對書中一些編程習慣、應用上有意見,但這些是見人見智的,所以也沒有批評,只隨便找幾個在下認為是錯處的地方出來。如果肖先生認為那些不是問題、沒錯,也歡迎交流。
  
  也許肖先生認為出版書籍只要銷量好就行了,那我也沒話好說的。

2010-01-26 11:03:40 Milo

  肖先生還是沒有正面回應我指出的錯誤。
  
  我認為肖先生分享經驗是好的,我善意把找出的問題寫出來,希望將來有機會續版的時候,能改進。但肖先生的回覆實在令人太失望。
  
  口裡說要小心翼翼、嚴謹,但對於書中的錯誤卻不承認,不斷說其他的事混淆視聽。
  
  我讀書,找到錯誤有時候會告訴作者,尤其是很喜歡的書,例如看 Real-time Rendering 第三版時,我看的時候發現前後文不對,懷疑 "BC4/3Dc" 應該是 "BC5/3Dc",說書的作者很高興地回覆我,並加到 errata 表上:
  
  http://www.cs.lth.se/home/Tomas_Akenine_Moller/RTR/corrigenda3ed_1print.html
  
  那麼其他讀者也能避免讀到不正確的內容,下一次印刷也可以更進一步提高質量。
  
  肖先生的書,雖然我還只是看了幾章,便因為錯誤太多而不想讀下去。而且那些並不是筆誤,是一些概念性的錯誤。或許書中確實有值得參考的經驗,但是,錯誤的知識會誤人子弟。
  
  也許正如令一位讀者說,這本書可以讓讀者側面看到內地業界的情況。我不希望內地的同學們不會跟從肖"老師"做軟件寫書的態度。
  
  P.S. 我是在上海工作的香港人,從事商業軟件開發只有十多年,使用 C/C++ 不足二十年。因為習慣我不把回應轉為簡體了,希望不要見怪。

2010-01-26 11:43:25 Milo

  更正: 我不希望內地的同學們"會"跟從肖"老師"做軟件寫書的態度。

2010-01-26 20:29:43 Binny

  @书作者 :
  Are you kidding? 0 bug impossible!
  看到你的书名,我怀疑你的这本书不是写给程序员看的,而是写给软件推销员看到吧?

2010-01-26 20:35:32 机械唯物主义

  个人感觉以上的一些讨论很多是项目相关的。甚至没有一个定论,有没有错我不知道,因为我C++不熟,不了解具体的实现。
  我知道一点:现在的程序开发,依赖的东西太多了,编程语言,编译器,操作系统,库函数,设备驱动,CPUcache和指令集优化,甚至还有语言本身内置数据结构比如浮点,整型的限制,内存收集机制等等。
  程序员几乎如履薄冰,每一步都要小心犯错(不靠谱的程序员除外),这个时候,程序员的个人修养和开发规范成为我们的保护伞,防止我们迈进bug的深渊。
  书我没有看过,但是感觉楼上的讨论有点偏,尤其是肖舸,最好不要用人身指代的词汇,把问题局限在技术上面。这样也可以说是讨论的原则,防止我们迈进“论战”的深渊。

2010-01-26 20:37:18 机械唯物主义

  用统计的话说:
  软件不可能没有bug,但是可以保证出现bug的概率足够低,低到统计上可以忽略的状态。

2010-01-26 20:43:30 赖勇浩

  高下立判。

2010-01-26 20:44:05 Milo

  我寫評語的時候,只看過當當網的評語。並沒有看其他評語,亦沒有和其他看過本作的讀者討論。我寫的評語,及我找到的問題,都是我讀的時候看到的。
  
  之前說過,我的書是購自當當的,你要懷疑可以看看 http://commu.dangdang.com/review/reviewlist.php?pid=20738772
  
  如果你細心再讀我第一篇評語,你可以看到我花時間去告訴你書裡的問題。我的語氣已經很客氣了,我認為已經盡量客觀的了。閣下有看到我在駡嗎? 反觀,閣下的回應夾雜對本人的輕視,甚至用一些比較"低俗"的字句(如 P),我不知道你作為"老師"是否也喜歡這樣說話的。
  
  第三章之後我還沒看,先回應關於閣下的回覆吧。

2010-01-26 20:57:10 机械唯物主义

  可能是肖舸刚出了书,意气风发中接受不了批评吧,语气激烈了些,milo消消气,大家把重心放在技术上,不要在无谓的地方浪费时间。
  作者应该感到高兴,因为有那么多人来帮助指导你提高。哈哈。
  知道这样,等我以后把python用熟后写本0bug python编程。然后等口水雨吧。。

2010-01-26 21:03:31 机械唯物主义

  可能是肖舸刚出了书,意气风发中接受不了批评吧,语气激烈了些,milo消消气,大家把重心放在技术上,不要在无谓的地方浪费时间。
  作者应该感到高兴,因为有那么多人来帮助指导你提高。哈哈。
  知道这样,等我以后把python用熟后写本0bug python编程。然后等口水雨吧。。

2010-01-26 21:08:32 机械唯物主义

  不管技术上面到底怎么样(我也看不出来),
  但从语气上,肖舸没有腔调。。。
  我还是离开这里吧。

2010-01-26 21:13:56 Milo

      - P.41 「CPU每个时钟周期,至少能通过总线访问到1个字节」是不对的。如果是这样,就不用L1、L2 Cache了。整个2.3.1是要说明为什么要使用锁,但这段说明是错误的。
    
  >  不要用PC机套,我的书讲跨平台的,可以理解包含Z80,总线访问最小粒度,抽象你懂不懂?研究跨平台,不是说每种机器一种说法,一个解决方案,而是抽象其普适特点来描述和讨论。因此,我一般就说总线至少一个周期能访问1Byte了。2.3.1我没觉得有bug。
  
  我以為一說作者就會明白。那我再把錯處說得明白一點吧。總線存取記憶體的時間,和 CPU 的時鐘周期是沒有直接關係的。所以 CPU 的每個時鐘周期不一定能通過總線訪問到一個字節。在實際的情況下,cache miss 引發
  的 CPU stall 可以是幾十甚至幾百個 CPU clock cycles 的。這個概念對現代的編程尤其重要,因為 CPU 的速度比記憶體的速度快很多,所以編程時要盡量增加 cache coherency 去提升效能。
  
  
  2.3.1 的標題是「為甚麼要用鎖」,作者以一個32-bit內存空間被多個線程訪問作為例子去解釋,並說計算結果寫進內存時,寫了16-bit後被另一個線程讀取,所以會出現錯誤。這並不是需要鎖的真正原因。32-bit CPU 存取內存並不會出現以上的情況。但是還是需要鎖的,因為在現代的 SMP (Symmetric Multiprocessing) CPU 下,會有內存和 Cache 的同步問題。P.42 中說到「可以使一個字節的內存單元保存的狀態(1 字節的操作不會被打斷)」,在 SMP 下也是不行的。作者的說法也許在 16-bit 時代的 CPU 有可能有效,但我認為在概念上是一個不正確的解釋。
  
  所以我認為整段 2.3.1 應該重寫。個人建議,如果不想說明這些底層的問題,也可以簡單說明一個或一組資源(除了內存,一些設備也需要的) 為了不被多個線程/進程存取,導致 inconsistency 而引發錯誤,就需要使用操作系統提供 (或對每個平台編寫) 的同步機制。

2010-01-26 21:15:50 机械唯物主义

  谁骂你了?在讨论问题哪。
  
  “IT界怎么出了你们这帮东西? ”
  这是典型的人身攻击,我脸皮厚无所谓,
  只是你平时也会这样说话吗?你看见那个牛人会这样骂人吗?

2010-01-26 21:21:44 机械唯物主义

  上面访问时间的问题,我虽然不是科班出身,原先看csapp也有一定了解,
  看arm结构也知道了一点,
  就是时钟信号是拿来同步用的,而取得的数据有可能是放在cache里面,有可能miss掉,再从内存里面取(硬件实现),
  不过书中原文没有看过,不知道是不是说这个问题?因为看不到上下文。

2010-01-26 21:24:35 机械唯物主义

  上面访问时间的问题,我虽然不是科班出身,原先看csapp也有一定了解,
  看arm结构也知道了一点,
  就是时钟信号是拿来同步用的,而取得的数据有可能是放在cache里面,有可能miss掉,再从内存里面取(硬件实现),
  不过书中原文没有看过,不知道是不是说这个问题?因为看不到上下文。

2010-01-26 21:28:58 机械唯物主义

  邮箱多少?我把列表转发给你。

2010-01-26 21:34:50 萧萧

  别人自己认为0 bug就0 bug啦,你们跟一自言自语的人叫什么劲啊

2010-01-26 21:35:38 Milo

      - P.45 整页说明Windows 加锁有漏洞、不严谨。文中没说是那种"锁",估计是Mutex。 Windows的Mutex是recursive的, Linux 预设的是non-recursive,但也可以使用recursive mutex的。这应该不是Windows的错而是作者的错。
      
  >  做程序,懂不懂抽象啊。各种系统提供了形形色色的锁,有临界区,互斥量,信号量。。。,我研究跨平台并行开发,要不要抽象出一个通用锁概念来描述啊。
  >  我的书讲实战,实战中,我发现double lock,Windows不挂,Linux挂,我就说Windows有问题,要想办法解决。至少,我在书里面是提出这个要点,请各位程序员关注,这个也是罪过吗?至少,我是Windows的用户吧,它的特性不能满足我这个用户的需求,我是不是一定要削足适履啊?
  >  照你说法:Windows是没有错误的,如果各位程序员出现问题,只能检查自己人品,而且还不准想办法解决。呵呵,那大家干脆上吊算了。
  
  我理解作者面對一個問題後,找出了自己的解決方法,這當然是每個程序員都要的做的。但作者把那個問題歸咎於「實際上是Windows操作系統不嚴謹造成的」,這才是我想說的錯誤。
  
  不同操作系統提供不同的同步機制,當中有異同,但我們應該要理解這些異同。Recursive mutex 是很有用的同步機制,但書中(或許作者)並沒有指出,而把它說成 Windows的錯誤。所以我會認為這段是一個錯誤。
  
  做 Hardware Abstraction Layer (HAL) 閣下是明白的。我沒試過一些情況要用 non-recursive mutex,剛剛查了一下,應該可以用一個 binary semaphore 去實現的。
  
  閣下用「Windows不挂,Linux挂」推理 Windows 有問題,而沒有找出真正的原因。我告訴了你原因,反而不斷反問我你錯在那。

2010-01-26 21:40:55 Milo

      - P. 86 「由于C 和C++ 语言,标签在编译时一般都具有全局性,因此,一定不能重名......」标签只需要在一函数内不重名就可以,goto 也只可以使用同一函数里的标签。那种全域命名方式是没需要的。
    
  >  不管全局标签有没有必要,我从命名上规范标签具备全局唯一性,效果只会更好,是不是这样?请问有没有问题?
  
  效果是否更好,這是見人見智的。我說出的錯處是「由于C 和C++ 语言,标签在编译时一般都具有全局性,因此,一定不能重名......」
  
  這是對 C/C++ 語言對標簽理解的錯誤。

2010-01-26 21:41:28 机械唯物主义

  这样的评论很正常啊。。。
  

2010-01-26 21:45:02 机械唯物主义

  「由于C 和C++ 语言,标签在编译时一般都具有全局性,因此,一定不能重名......」
  我也觉得,不能重名是原则,要遵守,
  但是标签是否全局,这个是个事实,要查文档,给出出处,到底是语言标准,还是交由编译器自己实现。
  考据,是技术书籍非常难写的一个原因,但是非写不可。。我觉得。

2010-01-26 21:52:11 Milo

      - P.91, 127 说ternary operator (即a ? b : c) 没用,用if-else 可以原全取代。这是 expression 和 statement 的分别。例如你不可以用if-else 写一个MAX(a, b) 的宏。
    
  >  如果我写出来一个呢?你怎么说?
  >  看好啊,我就不收你学费了。免费教你:
    #define MY_MAX(r,a,b) \
    { \
    if(a>b) r=a; \
    else r=b; \
    }
    
    inline int MY_MAX_1(int a,int b)
    {
    if(a>b) return a;
    else return b;
    }
    
    void test_MY_MAX(void)
    {
    int a=1;
    int b=2;
    int r=0;
    MY_MAX(r,a,b);
    printf("%d %d\n",r,MY_MAX_1(a,b));
    }
    这里我给出两种情况,一种是inline带直接返回,另外一个是直接宏实现,仅仅调用格式有点差异。
  
  
  多謝賜教。但我說是 「MAX(a, b) 的宏」。你是不明白 「MAX(a, b)」 還是不明白「宏」?
  
  MAX(r, a, b) 因為包裝的是 statement,所以做不到一個 expression 要做的事。例如 return 10 * MAX(a, b);
  
  當然,你可以在編程規範裡禁止使用 ternary operator。我所說明的,是這個 operator 和 if-else statement 是不能直接取代的,所以才說是錯誤。
  
  inline function 可以解決我提出的問題。但 inline function 是 C99 才提供的,但不支持 C99 的 C compiler 就經常要用宏,ternary operator 也經常要使用。
  
  另外,我個人是接受使用 ternary operator 的,當它能使一段程序更簡而清。這點個人喜好的不同並和我上述評論無關。

2010-01-26 21:52:35 机械唯物主义

  个人总结几个问题:
  肖舸你觉得被骂了,所以你愤怒是不是?先说我认为应该怎么回应。
  说有问题的,回应解。说有错误的,回应讨论。人身攻击的,不回复。
  如果你觉得我们是鸟人,你应该证明我们是鸟人。。比如我们有翅膀之类。。。这才是正统的回应。
  骂人是没有建设性的。

2010-01-26 22:00:54 机械唯物主义

  刚才写了一下,果然, statement和expression的概念是不同的。。。

2010-01-26 22:04:51 机械唯物主义

  试图影响我书的声誉和形象。。。。
  拜托,书评区就是用来影响书的声誉和形象的呀。
  如果你觉得有书评不合适的话,找管理员删帖就好了呀。
  我知道你要卖书,所以关注书评,希望大家捧的多。
  但是人们怎么说,你还要控制,和GCD有什么区别?

2010-01-26 22:04:56 andy

  哈哈..终于把号注册好了,我本来想说,肖老师,你鸟他们搞毛啊..自会有你的书的读者来抱不平的..我是不行了,因为我太菜鸟了..
  不过,你有一句我很同意...把名字报出来!!
  然后再PK...
  名字都不敢说的..算什么英雄.人家乔峰到哪儿不是说自己叫乔峰..
  

2010-01-26 22:05:52 [已注销]

  从twitter上看到这篇评论,进来看了一下。建议halida和Milo不要再说了,因为看得出来作者不够冷静,还不能理性的接受别人的批评,都散散吧。

2010-01-26 22:06:46 andy

  你们敢报名字么.......其实他们说肖大你..你应该感到高兴啊..我就是JAY的粉丝..我就看到很多人损JAY为什么呢.因为他红啊..他火啊...为什么他们骂你呢...你红呗..你在学生大本营里.人气这么高.......

2010-01-26 22:08:15 andy

  一个在晚上,一个在白天.一个暗,一个明..他们找得到人报复..你找不到...哈哈..

2010-01-26 22:09:09 andy

  他名都不敢报..其实肖大你在这里...唉..也就练练打字..我也是.练练打字...

2010-01-26 22:09:58 andy

  在古代,战场上.英雄们一般都说一句.挑战者.报上名来.吾不杀无名之辈...

2010-01-26 22:10:29 机械唯物主义

    从twitter上看到这篇评论,进来看了一下。建议halida和Milo不要再说了,因为看得出来作者不够冷静,还不能理性的接受别人的批评,都散散吧。
  +1
  
  其实我是好玩,在这里做培训,以后会在生活中想办法让人变专业些,平时练练。

2010-01-26 22:10:40 andy

  在古代,战场上.英雄们一般都说一句.挑战者.报上名来.吾不杀无名之辈...

2010-01-26 22:14:19 机械唯物主义

  我是无名之辈,没有写过什么东西的,有名号的人一般没有时间来战的。
  真名什么的建议大家不要到处说,现在是敏感的时候,说了真名对生存不利。
  但是假名还是靠谱的,网名没有变过。以后也不会变,要么是机械唯物主义,要么是halida。
  还有就是,真名有什么重要的?都在网络上混,做出的东西也是挂假名,可以相当于古代的字号了。

2010-01-26 22:16:09 Milo

      - P.102 作者说类只使用public 和private,不知道为什么要有protected,说看不出protected和friend的用途,所以建议大家不要用。这两个关键词都在类的封装中有重要及无法替代的用途,建议作者看相关书籍。
    
    我书里面有讲的,你要是仔细看能看到,在现代多任务开发中,锁域是很重要的概念,一个类成员变量,被锁保护,要求其暴露的公有接口尽可能少,避免不小心出现锁漏洞,发生未保护访问。但是,继承和多态,特别是再加上protected和友元,是类成员变量,成员函数的“视界”(看得懂这个词不?就是一个成员函数能看见,访问的变量范围),成员变量的被访问域,都模糊不清,这在多线程开发中极其造成bug。
    所以我回避使用。我没觉得我这么说有bug,我也写了20几年程序了,起码,不这么用,我也赚到饭钱了。
  
  P.102 說,「筆者看不出 protected 有甚麼用途。...同時也不要用友元設計。」嚴格來說,這並不是一個錯誤。我把它歸類成錯誤是我不對。只可以說是筆者不會用這兩個關鍵詞。就好像不用 private 也可以寫出沒錯誤的程序。
  
  首先說說 protected。這是 inheritance 才有用的 visibility。目的是把 public visibliity (所有類別可存取) 減少至 derived class 可存取的 visibility。在 inheritance 中能增強 data encapsulation。
  
  friend 也是改變 visibility 的關鍵字。最常見是 override binary operator 時要使用的。另外,在 Factory pattern (或其他相似 pattern) 中,也可以把 constructor private,然後給予 Factory class friend visibility。
  
  當然,以上例子裡,把 visibility 升級至 public 也不會做成編釋錯誤。C++ 只是提供這兩個 keywords 去增強 data encapsulation 而已。
  
  一些語言提供另外的 visibility keyword,例如 C# 有 internal keyword 而沒有 friend,去分別模組內類別和模組外類別的 visibility。

2010-01-26 22:18:12 机械唯物主义

  攻击有可能,出版界可能很黑暗,我不是这块的不了解。
  大学生应该指我,我没有进过商用程序的项目,可以说是大学生级别的。不过我没有骂人,只是在这里顶骂名。(好吧,我说过一句没腔调没肚皮)
  书没看,我也不评,我只是围观书评。
  

2010-01-26 22:23:52 机械唯物主义

  Milo说的还是很靠谱的。。。类访问机制是拿来做抽象的。。和具体实现的功能是不影响的,是否可以这样理解?
  这些抽象都是防君子不防小人。

2010-01-26 22:30:11 lzprgmr_闭关

  本来想发表几句,看到最后变成口水战了(一个人的口水),甚是失望

2010-01-26 22:32:37 Milo

      - P.109-P.111 对C++物件模型的错误解释。那个物件的「函数指针表」是不存在的。有虚函数的类才需要每个物件多出一个虚函数表指针,指向一个类的虚函数表。另外为解决内存碎片问题,C++物件中应该用placement new、new operator重载或/和显式解构。
    
  >  还是抽象,本书不是一本C++的入门和深入的书籍,主要是帮助初学者迅速建立概念,能大概理解为什么要做一些特殊的规避设计的意义,你指出这个问题,其实不是本小节讲的重点,本小节讲的主要目的,是解释为什么我会采用一种很奇怪的写法,即不直接写类,而是先把类成员变量做成结构体,采用C方式实现访问方法,最后再来封装类,这个问题,已经在网上解释过了,就是为了回避内存碎片。具体可以参考原帖:http://student.csdn.net/space.php?uid=39028&do=blog&id=21198
  >  因此,这里的函数指针表是虚指,是解释为什么可以把类成员函数和成员变量剥离,因为有这么个原理,你100%照着C++标准套,当然不合适。嗯,我再说一遍,不要用C++标准套,C++并不是很好的服务器开发语言,甚至,也不是并行开发语言,其很多高端特性,大家津津乐道的一些体现C++正宗的特性,继承啊,多态啊,泛型啊,一套到多任务开发就完蛋。STL我就不认为适合多任务开发,起码,作为纯语言库,它不包括对操作系统的访问控制方法,因此,没有包含对锁的使用和优化,多任务开发,STL基本无用。
  
  我剛剛看了閣下和陳碩先生的對話,可以肯定地確認我的想法,就是閣下對 C++ 物件模型並不太認悉。
  
  第一點,P.108 「C++中類和結構體其實很相似,都是由變量區和函數指針表構成的。其中,函數指針表包含所有內部成員函數的指針,......」和 P.110 的 圖3.1
  
  很明顯作者閣下對 C++ 物件模型有誤解。以下對話亦顯示出這個問題:
  
  "肖舸: 嗯,还有个原因
   C++对内存的使用,你不觉得太奢侈了吗?
  
  陈硕: 呃,说实话不觉得,每个对象的大小是可知的,new 一个 class 和 malloc 一个 struct 消耗的内存一样多。
   如果你指编译后的代码大小,那我部分同意
  肖舸: 关键问题出在你我都讨厌的一个东东
   继承
   不是代码大小,而是其运行空间要求,比较奢华
   C++的开发者,没有考虑很多极限情况
   比如,64M的arm
  
  陈硕: 继承在没有虚函数的情况,没有额外的内存开销
   其实C++的诞生环境比这个还恶劣,82、83年那会儿4M都是很奢侈的
  
  肖舸: 可是,谁玩继承会不玩虚函数?
   其实,模板也很奢侈,起码我这么认为
  
  陈硕: 虚函数的话,每个对象大4个字节,用了存虚表指针,似乎也不算很多
  
  肖舸: 不是,嗯,这个也是我的感觉,也没做太多测试
   我总觉得,泛型设计,考虑问题太多,内存耗用过大"
  
  我所指出的問題在於書中的"(2)C++類和對象深入研究"該節下,錯誤描述 C++ 物件模型。
  
  
  第二點,對於作者透過一個 class aggregate 一個 struct 去解決 custom allocation 的問題,這不是一個錯誤,只是一個冗餘的做法。
  
  沒有 polymorphic 的 class,可以簡單用 custom allocation,再調函式初始化。但統一的做法是,使用 placement new 去調用物件的 constructor,並最後用explicit destructor call。
  
  這樣跟本不用增加一個 struct 去解決問題,亦減少了 indirection 和 memory fragmentation 問題。
  

2010-01-26 22:36:41 那谁

  起初仅是对内容不看好,不过还不至于太失望,毕竟还有一些自己的想法,看了今天这个回复,已经是对作者本人失望了,我路过.
  
  

2010-01-26 22:37:15 fleuria叔

  路过,仅围观

2010-01-26 22:40:27 Milo

      - P.118-119 对头文件依赖问题错误描述。 Forward declaration 只能声明一个型别的存在,所以只能使用其型别的pointer或reference,而在例子中用A a是不行的。一个header #inlclude 另一个header是很正常的做法。
      
  >  这个就是吹毛求疵了,这个A a,我想说明的是另外的问题,你非要说不符合,我也没办法,我书中那么多符合的你不说,非要跳出一句话,我不是讲这个意思的例子,来说明,我实在无话可说,只能说你是恶意断章取义了。
  
  
  「建議的寫法如下: 在 b.cpp 中包含 a.h,即把#include "a.h" 這句話寫在 b.cpp 中; 而在B的類聲明前手動聲明 A 即可。
  
  class A; // 手工聲明 A 是一個類
  class B
  {
   A a;
  };
  」
  
  這一段描述明顯錯誤。因為 class B 內不能寫 A a; 只能寫 A* a; 或 A& a;。
  
  這是 C/C++ 中很重要的知識。要減少 #include,利用 forward declaration,就必須使用 pointer 或 reference。這對於 API 設計是很重要的。所謂的 Pimpl 手法,就是利用這個減少 dependency。
  
  但這個手法帶來 indirection 的開銷,所以要按情況決定使不使用的。
  

2010-01-26 22:54:42 Milo

      - P.126 说不需要用 ++i 只需要用 i++。在C++ 里是建议相反的,因为物件的post increment/decrement operator是需要额外的copy construction。
    
  >  ++i和i++见仁见智,本来就都可以,C++可以建议++i,我当然也可以建议i++啊,凭啥C++放个P都是香的,我这里写一点自己的看法就是大逆不道?
  
  這也不是香不香的問題,而是效能的問題。
  
  在 C 裡,i++ 和 ++i 並不影響效能,只是語意上的問題。即 a = i++; 和 a = ++i; 執行結果中 a 的值是不一樣。
  
  而在 C++ 裡,兩個 operator++ 也可以被重載的,但 post increment 必須回傳影響前的 object,所以效能較慢。舉例:
  
  class A {
  public:
   // pre-increment
   A& operator()
   {
   DoIncrement();
   return *this;
   }
  
   // post-increment
   A operator++(int)
   {
   A a = *this; // call copy constructor
   DoIncrement();
   return a; // call copy constructor
   }
  
   void DoIncrement();
  };
  
  ++i 有時候比 i++ 快,但永遠不會比 i++ 慢。所以 C++ 中才會建議用 pre-increment/decrement operator的。
  
  如果要 P.126「從一而終」,應該選擇 pre-increment。

2010-01-26 23:01:32 Tinyfool

  受够了Milo了,你不就是比作者懂的多么,你比他懂得多,你还买这个傻瓜的书做啥?这不是调戏弱智儿童么?这是多么无耻的行为啊?

2010-01-26 23:05:17 Milo

    - 书中很多string/buffer 长度、sizeof() 的结果等,都使用int 型别。正确的型别应该是size_t。
    
  >  原来我做VC的时候,很喜欢界定这个size_t,不过,近年来已经改回int了,原因很简单,Linux的习惯,或者,这是所有Unix like的OS的C程序员的习惯,int代指一切。
  >  如果大家多读读Linux的内核编码,可以看到太多的int了。
  >  这个呢,见仁见智,我没有坚持我的就是真理,大家喜欢的,请自行使用size_t来替换,我的书本来就没有提供源代码的,有兴趣,就敲敲看,敲的时候,注意替换成size_t就好了。
  >  嗯,这位读者,起码你没有看到我书中有一句话,工程库的开发和维护,“尊重”是第一原则,一段代码,只要run起来,被证明为稳定可靠的,就不要为改而改,哪怕再不正规,先尊重。保持这个稳定运行的结果最重要。
  >  好比你要做Linux程序,是不是先把源代码过滤一遍,把所有你认为不符合C++标准的代码都改过来,这才会用?
  >  如果你这么做,猜猜老板会怎么对你?夸你?还是炒了你?
  
  Linux 內核我是沒看過的,如果真的是如此,我會去研究一下為甚麼。
  
  但 size_t 是 unsigned type,int 是 signed,所以表示的 range 不一樣,基本上我使用過的 compiler 也會報 warning。
  
  再者,如果在 32-bit OS 中能 malloc(s) 而 s 是大於 2GB的,那麼就會有問題,因為 s 本身是負數。當然實際上,某一個 OS 是否容許 malloc 2GB以上的內存,是一個 platform-specific 問題。
  
  暫時我個人認為 size_t 的 parameter (如 void* malloc(size_t)) 或 sizeof() 應該是使用 size_t 型別的。

2010-01-26 23:06:23 猛禽

  哈哈,Tinyfool说得好。
  作者水平怎么样就不说了,能召唤到这么多高手来围观,那也不是一般人啊。

2010-01-26 23:08:32 大師

  我对这个专业一窍不通,在推特上看到了过来看一眼。
  感觉这位作者肚量太小,有问题讨论问题,态度那么恶劣干什么。

2010-01-26 23:12:26 Milo

  2010-01-26 15:08:15 肖舸
  >  根据你对本书的评论,我也点评你一句:
  >  “形而上学”
  >  你是香港人,可能没有上过大陆政治经济学的课程,可能不一定懂这个词,可以请教一下你身边的大陆朋友。
  
  剛才花了時間回應你的回應,寫得比較慢,不好意思。
  
  形而上學應該是 metaphysical 吧。閣下說對了,我沒上過大陸政治經濟學的課程,但我在本科有讀一點哲學的。謝謝你的點評。
  
  不過我覺得我的書評和 metaphysics 沒大關係,只是把一些我認為客觀上不對的東西抽一點寫出來而已。也沒有批評書中的一些非錯誤、但我個人不認同的事情。

2010-01-26 23:17:37 Milo

  2010-01-26 21:00:48 肖舸
  >  请你也耐心读一遍我的回应。
  >  如果理解不了呢,再作几年程序再来理解吧。
  >  起码,我现在每天还在做程序,嗯,老板还没有炒我,Mantis上,还暂时没有我的bug。
  >  不是说任何一个读者跑过来说我哪点错了,我就无条件修改的,我还有我自己的判断呢。
  >  怎么着,逼着我改错了,好再骂?
  
  我很耐心讀完你的回應,我覺得我已經理解了,也很耐心地回應你的回應。
  
  當然作者看到讀者的回應,應該會細心思考,可能之後再以討論(包括該讀者及其他人)的形式冒求改善。
  
  我怎麼逼你了。更沒有駡。

2010-01-26 23:22:06 refactor

  其实我倒不在乎作者0bug的说法,只要书确实能对我有帮助就行。
  今天这篇评论我从头看到尾了,高下立判,评论者的严谨让人佩服,作者的胸襟嘛,其实无所谓,看书又不是看人。还好,庆幸当日没在书店冲动买下。

2010-01-26 23:22:59 Milo

  2010-01-26 21:14:48 肖舸
    那就麻烦你帮我重写,你都懂完了,麻烦自己写书。
  > 删除
  2010-01-26 21:15:27 肖舸
    顺便问问,你写过多线程开发没有?
  
  有機會我是想再寫的。我以前也出版過一本書籍,知道當中的困難。
  
  在我的職業生涯裡,我寫過多線程的程序的,也設計過伺服器的架構。不過近年的職位主要做client-side,也需要多線程的。

2010-01-26 23:27:09 老猫

  Milo不要浪费时间了,比起在这里苦口婆心循循善诱,还有很多更有意义的事情可以做,比如逛街吃饭等等。

2010-01-26 23:28:45 SpitFire

  大家洗洗睡吧,这本书已经没啥好评论了

2010-01-26 23:32:30 eating

  有意思

2010-01-26 23:35:23 老赵

  嗯,不错,围观。
  肖老师好,我来曝实名了,我的博客是 http://www.cnblogs.com/JeffreyZhao/ ,我会继续关注这贴的。

2010-01-26 23:36:30 大師

  土逼,我骂你怎么着?你好意思出书挣钱就要有被拍的觉悟,管被几个人拍,拍的就是你,怎么了,谁让你出书了?你出的书傻不傻逼都拍你,就拍你!我本来就是觉得你没肚量罢了,原来你就是一傻逼,我连Hello world都不会写我就敢肯定LZ说的肯定是对的,你肯定是错的,因为你TM脑子少根筋。
  
  别TM装可怜什么狗屁弱势群体,郭敬明虽然遭人唾弃至少还有芸芸教众为他护法,你在你自己的书目下面都吸引不到力量来帮你,这是一种什么样的国际主义精神?这TM叫自作孽不可活!什么叫“做人不能无耻到这个地步”,Programming界的无极,Programmer界的陈凯歌。

2010-01-26 23:38:45 [已注销]

  > Linux 內核我是沒看過的,如果真的是如此,我會去研究一下為甚麼。
  多嘴一句,内核里面通常是用u8,u16,u32和u64之类的类型的,否则会有移植问题。详情请看 Linux Device Drivers 第三版, 第11章。
  
  

2010-01-26 23:38:56 老赵

  忘说了,支持Milo同学继续读书,继续捉bug。
  我觉得你的评论有价值,无论正确与否,可以引起良性的讨论和技术深入,我支持你。

2010-01-26 23:41:02 老赵

  肖老师,我其实不是支持你的,只是我也打算在博客上说你坏话,所以希望你可以关注一下……

2010-01-26 23:42:47 sprite

  今晚热闹啊,Tinyfool和老赵居然同时都在刷douban

2010-01-26 23:43:45 Tinyfool

  恩,我倒是很少上豆瓣的…没文化看书看得少

2010-01-26 23:44:29 庄表伟

  twitter观光团,前来围观

2010-01-26 23:46:39 Milo

  2010-01-26 22:00:42 肖舸
  >  那位香港人,如果你真心是想讨论书的技术问题,请翻到书的最后一页,里面有我建议的读者俱乐部地址,只要到读者俱乐部好好发帖,我们慢慢讨论,没有问题。
  >  但是,在这里以写书评,试图影响我书的声誉和形象呢,我可真不接受。
  >  万事讲方式方法,我已经给出了良好的建议,你不遵守,乱来,我也只有不客气了。
  >  嗯,还有一个,这些网上马甲号众多,你不报实名,也确实不要怪我把你当马甲号狂拍。
  >  感觉你不是在讨论技术,一个是想吹嘘你自己,“你看,我比作者都牛”,另一个呢,就不知道什么目的了,也许真是马甲号也说不定。
  >  我还是那句话,读者和作者交流,讲个诚信,报实名,我们慢慢谈,可以,但是乱来的话,就只有不好意思了。
  
  我雖然不理解實名有多重要,因為我只談客觀的事情。沒有用我的身份地位或甚麼經驗作為評論的論點。我的實名就是 Milo Yip,你可以用MSN/E-mail miloyip@gmail.com 聯系我。
  
  我一開始的時候是純粹地討論技術。閣下的回覆也真令我有點氣憤。但我已盡量控制我的情緒,保持冷靜地回覆。
  
  沒有人懂得一切事情,也許閣下的某些經驗是我所需要的。但同時,本人認為編程和寫書都是需要有嚴謹的心,就如貴書第12章說,「細節決定成敗」。我知道閣下是第一次寫書,可能沒料到有讀者會有這樣的回應。
  
  閣下有沒有想過,一些初學者如果把錯誤的訊息信以為真,解決一些你書中以外的問題時,可能會遇到更大的困難? 所以寫、譯技術性的書籍是很困難的,我愛書,所以也欣賞寫的好的書,也想藉指出問題來改善相對一些比較不那麼好的書藉。
  
  我沒讀完整本書便作出評分,必許是一個不太嚴謹的行為。但是指出我看了的部份的問題,拿來討論,應該不是問題吧。
  
  有空我看完,或許再寫一次書評吧。不過最近已累積了不少未閱書籍,這幾天也花了這麼多時間寫書評,或許要在等一段時間。

2010-01-26 23:47:18 老赵

  @肖老师
  其实我发现这里好像一直是您在谩骂,对方的态度是很好滴。
  
  @sprite
  我是趁热闹赶快推广博客咯。

2010-01-26 23:47:55 大師

  好意思讲得出来,这贴里对作者帮助最大的就是LZ,结果被作者直接裁决成某些集团来唱衰作者的了,还说什么可以讨论问题,结果还是您”同意的“才能讨论,讨论什么?还有什么好讨论?TG都没您那么高的河蟹水平,您就是王,您说我国互联网是开放的,还有谁敢说不是?
  ----------------------------------------------------
  2010-01-26 23:41:22 肖舸
    这个zhao先生说法我认同,捉bug,我同意的,可以讨论。
    我书后面有读者俱乐部的。欢迎进去报bug。
    不过,要讨论的,不能你说啥就是啥,起码我这个作者还是有发言权的。
    
    我的原则:
    真心想帮助这本书的,是好朋友。
    谩骂的,嗯,我不客气。。。

2010-01-26 23:48:06 SpitFire

  我实在看不出Milo在胡搅蛮缠,大家都是写程序的,严谨一些不是过分的要求

2010-01-26 23:50:06 [已注销]

  说句题外话,去了一下作者公司的主页,感觉是做VoIP的。想问一下这个FreePP跟其他类似的基于SIP的软件有什么优势呢?比如说Asterisk和SER?
  没有别的意思,只是感觉做这种企业产品很有钱途顺便问问。

2010-01-26 23:50:31 [已注销]

  份量有了,气量不足。
  
  看到前辈挂出一串头衔那一行,令我不禁想到国内的专家和教授们,他们如此在乎这些虚名。
  
  就取财的角度而言,无可厚非。
  
  而从传道授业解惑的角度来说,学生学到的可不仅仅是技术,还有脾气和方法,后者才是容易误人子弟的地方。
  
  吐口水和乱抛异常一样令人不快。

2010-01-26 23:50:35 sprite

  Milo如果你看完了(但愿),希望能够整理出一份比较完整的errata

2010-01-26 23:56:19 赖勇浩

  看了 Yip 老师的真名,作为游戏业内人士,我想我真是眼睛瞎了,不识高人。至于肖老师,根据你做的项目和 Yip 老师做一对比,你差了至少一个数量级还是可以说得过去的。你还是赶紧儿遁了吧。

2010-01-26 23:57:02 refactor

  这个超级看得津津有味,香港人修养真好,说话也很严谨有逻辑,而这个作者似乎认为没有下过鸡蛋的就不得批评鸡蛋做的难吃。有意思

2010-01-26 23:58:09 Tinyfool

    @肖老师
    
    一个服务器应用两年,运维没有报过bug就叫做0bug了?
    
    那也太简单了。
    
    无数互联网公司用apache很多年也没发现过bug,那么apache没有bug了? (当然有互联网公司发现过,但是更多互联网公司的运维5-6年也没发现过一次吧)
    
    我06年写的服务某商业网站用了3年多,也没有发现我程序有bug,那我是不是道行就比你高一年了?(当然我自己、team里面的同事和别的客户找到过bug)
    
    Joshua Bloch说sun当年Solaris上面的多线程实现有几个星期,代码都有个巨大的错误,lock和try-lock的汇编代码被弄反了,但是公司里面谁也没有发现。那么Solaris就算没bug了么?
  

2010-01-26 23:59:14 North Bridge

  散了吧,有意义的事情多了,何必浪费时间呢。。。 不买他的书就是了

2010-01-27 00:01:42 [已注销]

  2010-01-26 23:55:47 肖舸
    我也说句话,各位真要是公道,看看我的博文,看看我有没有大家说那么恶劣。
    做人要厚道。
    大家说我今天晚上脾气不好,我承认。确实说了很多过火的话。
    不过呢,我也反问一句,看我博文,平时我还是比较淡定,如果大家能把一位这么淡定的人,逼到骂脏话的话。。。
    大家是不是很有成就感?
  
  -----------
  
  想和刚接触的人做朋友,可以先摸摸他生气发火的底限在哪里,要是话不投机,成本不高,要是酒逢知己,成本同样不高:)
  
  各位前辈继续,我等着围观学习。

2010-01-27 00:03:30 罂粟

  看到这里忍不住笑了。支持你就叫公道点吗?我觉得Milo辛辛苦苦给你挑错公道得很哪。
  
  ----------------------------------------------------
  
  2010-01-26 23:57:35 肖舸
    我还真不信了,今天晚上,一个公道点的都没有?
  
  

2010-01-27 00:04:15 秋天的酸奶

  twitter观光团飘过,楼上是我偶像

2010-01-27 00:04:33 赖勇浩

  那位香港人,如果你真心是想讨论书的技术问题,请翻到书的最后一页,里面有我建议的读者俱乐部地址,只要到读者俱乐部好好发帖,我们慢慢讨论,没有问题。
    但是,在这里以写书评,试图影响我书的声誉和形象呢,我可真不接受。
  ===================
  这个未免搞笑了。
  他(或我)有随便自己的意愿在想在哪里评论就在哪里评论的权利,干嘛一定要去你的读者俱乐部?还有,你咋觉得只要是在 douban 写书评就是”试图影响我书的声誉和形象”?

2010-01-27 00:07:49

  http://www.freepp.com.cn/?p=21&a=view&r=18
  肖老师的网站,大家去围观一下 title里面居然是"error:数据库错误...."还把sql给输出了
  真是"0bug的7*24小时系统"啊

2010-01-27 00:08:14 sprite

  Google了一把Milo的履历,那个汗啊...
  估计当初就是被书名吸引了

2010-01-27 00:09:29 不如相忘于江湖

  作者肖舸你今天晚上确实太激动了,我怀疑你是酒后上网,小心要吊销网线的啊。首先,书写出来了就要允许别人评论,这评论当然有赞扬也有批评;其次,针对评论您得按套路出牌啊,人家说你这错了,你不同意可以反驳啊,技术上不就交流起来了吗?不应该首先就质疑人家的动机,然后又顾左右而言其他,中间简直就破口开骂了,把一堆旁观的人都批成一小撮阴谋人士,我想光看milo提出的问题也不至于是枪手吧?一个出版社能找到这么高级的枪手来喷一本几千本销量的书吗?你还说人家是坐在网吧里的喷子,这样的喷子我估计咱大部分公司都付不起工资吧;最后就是作者您辩论得讲逻辑,大家都是搞计算机的,好歹也学了点逻辑吧,您总不能拿您的从业时间长,您的程序卖了钱了来证明您的程序就没bug吧,更不能说人家不能评论吧。反正就说这么多,楼主淡定,我看您也经常做免费教程,心地应该挺好,自己出的书当然自己特别爱了,但也不能护短,过犹不及

2010-01-27 00:10:31 Milo

  >2010-01-27 00:01:51 肖舸
  >  大家说这么多,无非想证明我这本书是垃圾。
  >  呵呵,我想问问,我的书卖了那么多,为什么只有一个所谓的 Yip 老师,来替大家分忧,一定要揪出肖某人这个害群之马?
  >  一本书12章,看了3章就开骂。
  >  嗯,说实话哈,这位所谓的老师,其实说的我并不认同。
  >  我有计算机为证。
  >  我想,做IT的,毕竟是搞研发,必要的尊重科学还是要有的。
  >  不能昧着良心说瞎话,计算机能work的东东,我们今天一定要找出一点bug来。无非多组织几个人来群P而已。
  
  本人敝姓葉, 粵音寫成英文是Yip。本人只在大學做過助教,及之後開過一些小培訓班而已。請不要叫我做老師,還沒有資格。
  
  我說過我只看了三章就評分是我不嚴謹。但討論前三章的事情應該沒問題吧。
  
  我也不是在否定閣下的軟件的成功,只是說出書中的問題而已。
  
  如果計算機能找到書中的bug,那編輯們也會很高興。但是,書和軟件一樣,很難去「証明」是沒有錯誤的。
  
  以我所知,在軟件工程上,要「証明」一個程序沒錯,是很難的。聽說有一個方法叫 formal methods (http://en.wikipedia.org/wiki/Formal_methods),不過要寫到一個合符需求的証明本身就是很難的。

2010-01-27 00:10:49 [已注销]

  肖前辈,我没看过你的书,所以不发表任何评论。
  
  花了不少时间追这帖子,只是想知道什么时候你能冷静下来看一看别人写下的文字。
  
  己所不欲啊。
  
  PS:求证,一只羊是白的,两只羊是白的,一万只羊也是白的,但能否证明所有的羊都是白的?

2010-01-27 00:11:53 罂粟

  2010-01-27 00:07:49 夏
    http://www.freepp.com.cn/?p=21&a=view&r=18
    肖老师的网站,大家去围观一下 title里面居然是"error:数据库错误...."还把sql给输出了
    真是"0bug的7*24小时系统"啊
  
  ---------------------------------------------------
  
  不,夏同学你一定是看错了,这个网站运行那么久了都没人报过这个bug,那按肖老师的逻辑这并不是个bug。这是个错觉,一定是个错觉。

2010-01-27 00:12:24 双木成林

  twitter围观团前来围观。。
  

2010-01-27 00:13:37

  从第一个回复起就没有正面回应过LZ的问题...

2010-01-27 00:14:15 [已注销]

  > 肖老师的网站,大家去围观一下 title里面居然是"error:数据库错误...."还把sql给输出了
  
  围观回来了,怎么出了deepthroat这种东西啊?坦白是不是你做的?
  
  "数据库错误 Table 'deepthroat.shl_' doesn't exist
  select * from shl_ where id=18 FreePP 为您提供融合通信系统"
  
  >  Google了一把Milo的履历,那个汗啊...
  他的确是大牛。

2010-01-27 00:15:10 秋天的酸奶

  2010-01-27 00:07:49 夏
    http://www.freepp.com.cn/?p=21&a=view&r=18
    肖老师的网站,大家去围观一下 title里面居然是"error:数据库错误...."还把sql给输出了
    真是"0bug的7*24小时系统"啊
  
  =========================
  It's not a bug, it's a feature!

2010-01-27 00:15:19 不如相忘于江湖

  刚说完作者你就又犯病了,怎么感觉您有“被迫害妄想症”啊,引用您的这句话“大家说这么多,无非想证明我这本书是垃圾。 ”我不曾从这么多楼里看出哪位说过这句话,milo更没说,人家只是挑出您书里的一些问题与您探讨,而您却直接将提问题的人打成“喷子”,您这是给自己制造敌人啊,本来是很学术的探讨,您却非要引到人生攻击上去,您的逻辑是不是有点跳啊

2010-01-27 00:17:22 ndv

  哎,昨晚早睡了点,没来得及围观...

2010-01-27 00:17:40 [已注销]

  2010-01-27 00:15:19 不如相忘于江湖
    刚说完作者你就又犯病了,怎么感觉您有“被迫害妄想症”啊,引用您的这句话“大家说这么多,无非想证明我这本书是垃圾。 ”我不曾从这么多楼里看出哪位说过这句话,milo更没说,人家只是挑出您书里的一些问题与您探讨,而您却直接将提问题的人打成“喷子”,您这是给自己制造敌人啊,本来是很学术的探讨,您却非要引到人生攻击上去,您的逻辑是不是有点跳啊
  
  =========
  
  广而告之。
  明天抄送CSDN,拖几个版主过来看看。

2010-01-27 00:20:18 Tinyfool

  肖老师貌似从来没被批评过,这么点小批评就炸毛了,唉。难道以前因为太牛一直在神坛上贡着的?
  
  这么几条负面的评论就扯到豆瓣的公正性上去了…
  
  那么有几十页批评的作者还不都自杀了…

2010-01-27 00:24:58 xlvector

  在我的印象中,号称0bug的好像只有knuth
  让我们再膜拜一下大牛吧
  http://www-cs-faculty.stanford.edu/~uno/

2010-01-27 00:25:41 sprite

  突然觉得DEK老大太精明了,那2.56刀原来就是封口费啊

2010-01-27 00:26:00 香依香偎

  肖舸的意思是,即便发现了错误,也要到“读者俱乐部”这种私密的地方慢慢谈,不适宜在这个公开的地方谈论,否则会影响书的销量。
  
  窃以为,豆瓣的意义,就在于公开的谈论。深入且营养的讨论可能可以促进内容的改进、作者名气的传播以及后续的销量。
  
  但是,自大的态度和愤怒的指责,对书的销量还真起不到什么正面的帮助。

2010-01-27 00:26:06 大師

  敢情公理原来在您那边的。原来骂您的都是反社会的。殊不知我们竟然都是Milo的朋友,来友情围观的。

2010-01-27 00:26:31 不如相忘于江湖

  肖舸您确实太冲动了,估摸着是很少被人喷,别说您了,就算是侯捷翻译的书下面喷的还不是得翻几页啊。这个帖子里大家都来看你表演来了,您这天马行空的,光制造敌人了,我刚发完第二个帖子,您的思维就又跳跃到了豆瓣公正与否,民主、暴民,创新上了,这都和技术问题有啥关系啊,能证明咱的程序没bug吗?
  
  说句题外话,就是因为您的态度够跋扈才引起观光的。我估摸着您明天酒醒了你得把你发的帖子都删了。

2010-01-27 00:27:01 赖勇浩

  我在我所有博客发文,也请我的朋友过来围观。
  我还真不信了,这个世界上,几个人一群P,就可以把公理给改了。
  ========================
  囧,肖老师不知道这里围观的很多人在 CSDN blog 的浏览量都比你大?30 万浏览量的博客能拉几个人啊……不要自视过高。

2010-01-27 00:27:40 sprite

  @xlvector
  
  同学我们想到一起去了,再次90度仰视DEK大

2010-01-27 00:29:58 Tinyfool

  哎呀,我的csdn blog没有30万,才22万,没资格批评肖老师了,被比下去了,丢人了

2010-01-27 00:34:49 悟怡

  我只能说Milo很强。
<前页123后页>

在哪儿买这本书?   · · · · · · 

>0 bug

0 bug
作者: 肖舸
副标题: C/C++商用工程之道
isbn: 7121098482
书名: 0 bug
页数: 561
定价: 68.00元
出版年: 2010-1

Milo的其他评论   · · · · · ·