大能的党员们,一定要备份这个热闹啊!!!!

炸馒头片儿

2010-01-27 09:42:13 来自: 炸馒头片儿((读)纯粹理性批判 66%)

当事人吵完架以后回过味儿来了,发现自己做了件无敌蠢的是,于是……丫的居然不是道歉而是删帖了……你丫以为你卓越啊……

http://74.125.153.132/search?q=cache:6UtA82NfNDkJ:www.douban.com/review/2949973/+%E8%82%96+site:http://www.douban.com/review/2949973/&cd=3&hl=en&ct=clnkRT

28人喜欢
  • 炸馒头片儿

    2010-01-27 09:44:36 炸馒头片儿 ((读)纯粹理性批判 66%)


    2010-01-23 06:20:48   来自: Milo
    0 bug——C/C++商用工程之道的评论 2 star rating2 star rating

      看到这本书的题目,既猜疑又好奇,作者有什么好方法去写无错误的软件呢?
      
      可是收到本书后,越看越觉得不对劲。本人才疏学浅,评论不对的地方希望作者不要介意。我第一次写这么长的书评。
      
      首先,本书内容中有大量错误的地方需要纠正。因为错误(不是错别字等小错误)实在太多,阅读时也没有一一记下来,只随便找些例子:
      
      - 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系列。
      
      最后,我还是支持作者分享原创的心得。希望作者在续版及新作能更进步。

    * 你认为这篇评论:
    * 有用
    * 17
    * 没用
    * 1

    * 推荐 推荐

    X
    登录 · · · · · ·
    Email:
    密 码: 忘记密码了
    在这台电脑上记住我
    >还没有注册...

    2010-01-25 12:41:00 肖舸
      下回买书,建议看清楚了再买。
      我这里有篇博文,看过本文的朋友,有兴趣的话,请看看我的博文。
      http://student.csdn.net/space.php?uid=39028&do=blog&id=21593
      嗯,对了,最近还给西安程序员俱乐部做了一些演讲,大家有兴趣也可以看看。网址在这里:http://student.csdn.net/space.php?uid=39028&do=blog&id=22005。建议大家先看看肖某人的水平和为人,再决定买不买,呵呵,免得买了又来后悔哈。
      嗯,有兴趣的朋友,先看看录像吧,我演讲中特别提到了,0bug这本书的核心价值,“为明天,云端计算模型下的并行开发做准备。”
      并行开发中有很多禁忌,特别是服务器开发中,有很多细节,和普通的应用程序开发不一样。如果看不懂,我只能说,有机会做服务器,就能看懂了。
      每个人口味不一样,每个人程序经历不一样,对程序设计的理解深度也不一样。很难说一本书能讨所有人喜欢的。
      谭浩强老师的书,挨骂大概是最多的,但无可否认,销量最大。呵呵,我的书要是能有谭老师的销量,我会笑翻的。^_^
      
    2010-01-25 19:09:47 Milo
      多謝肖先生回覆。 我是在當當買的,只看過評語就買了, 說實話有點後悔。
      
      我絕對沒有「駡」作者的意思,只是實事求事,把我看到的問題說出來。我雖然對書中一些編程習慣、應用上有意見,但這些是見人見智的,所以也沒有批評,只隨便找幾個在下認為是錯處的地方出來。如果肖先生認為那些不是問題、沒錯,也歡迎交流。
      
      也許肖先生認為出版書籍只要銷量好就行了,那我也沒話好說的。
    2010-01-25 23:51:58 肖舸
      我做商用程序的,对软件有自己的看法。
      我有讲过的,本书的0bug,可能比大家通常所说的0bug要严厉一点,产品卖出钱了,钱放到包包里面,并且,落袋为安,不能因为维护费用,再花出去,这叫0bug。
      同理,我写商用书籍,写书本意是给大家一点提示,但是,我还是要赚钱的,因此,销量我很看重。
      我从来就没有说我是学校里面的教授,我书中的知识点,当时,当地,确实发生过一些问题,用书中的技巧,经验,知识,解决了,我就认为它有用。
      关于本书实现0bug的技巧,我认为不难的,难的是照做。我照做了,所以,同事加班改bug,我回去哄娃玩,这是我身边发生的事实。
      其实书中代码不难的,敲敲看,甭管标不标准,甭管看得懂不,你试试。计算机是最公平的,能work的。
      我有句话,乱写代码,大师,博士,教授写的代码,照挂,小心翼翼,遵守规矩,小菜鸟也能写出好代码。
      一个规范,标准,有bug的代码,和一个不规范,不标准,没有bug的代码,我情愿选后者。因为,我的代码有bug,老板会扣我薪水的,严重的,还可能炒了我。
      0bug代码真不难,你都能写。
      起码,我们写的第一个C代码,hello world,是0bug的吧。
      那么,我们经过严谨的系统分析,把每段函数,每个模块有简化到hello world的程度,请问0bug还难吗?
      别讲了,敲敲看,程序员不怕敲代码的。
      
    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 14:58:06 肖舸
      唉,那我回复一下吧。
      别老是对人不对事,开口闭口就是我的态度问题。这么问话,没人搭理你的。仔细想想,是你的态度有问题,还是我的态度有问题?
      我想,就算是读者,花了钱,买了书,对于作者,起码的礼貌和尊重还是要有的吧。
      
      看好,我一个个回复:
      
        - P.41 「CPU每个时钟周期,至少能通过总线访问到1个字节」是不对的。如果是这样,就不用L1、L2 Cache了。整个2.3.1是要说明为什么要使用锁,但这段说明是错误的。
      
      不要用PC机套,我的书讲跨平台的,可以理解包含Z80,总线访问最小粒度,抽象你懂不懂?研究跨平台,不是说每种机器一种说法,一个解决方案,而是抽象其普适特点来描述和讨论。因此,我一般就说总线至少一个周期能访问1Byte了。2.3.1我没觉得有bug。
        
        - P.45 整页说明Windows 加锁有漏洞、不严谨。文中没说是那种"锁",估计是Mutex。 Windows的Mutex是recursive的, Linux 预设的是non-recursive,但也可以使用recursive mutex的。这应该不是Windows的错而是作者的错。
        
      做程序,懂不懂抽象啊。各种系统提供了形形色色的锁,有临界区,互斥量,信号量。。。,我研究跨平台并行开发,要不要抽象出一个通用锁概念来描述啊。
      我的书讲实战,实战中,我发现double lock,Windows不挂,Linux挂,我就说Windows有问题,要想办法解决。至少,我在书里面是提出这个要点,请各位程序员关注,这个也是罪过吗?至少,我是Windows的用户吧,它的特性不能满足我这个用户的需求,我是不是一定要削足适履啊?
      照你说法:Windows是没有错误的,如果各位程序员出现问题,只能检查自己人品,而且还不准想办法解决。呵呵,那大家干脆上吊算了。
      
        - P. 86 「由于C 和C++ 语言,标签在编译时一般都具有全局性,因此,一定不能重名......」标签只需要在一函数内不重名就可以,goto 也只可以使用同一函数里的标签。那种全域命名方式是没需要的。
      
      不管全局标签有没有必要,我从命名上规范标签具备全局唯一性,效果只会更好,是不是这样?请问有没有问题?
      
        
        - 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带直接返回,另外一个是直接宏实现,仅仅调用格式有点差异。
      
        
        - P.102 作者说类只使用public 和private,不知道为什么要有protected,说看不出protected和friend的用途,所以建议大家不要用。这两个关键词都在类的封装中有重要及无法替代的用途,建议作者看相关书籍。
      
      我书里面有讲的,你要是仔细看能看到,在现代多任务开发中,锁域是很重要的概念,一个类成员变量,被锁保护,要求其暴露的公有接口尽可能少,避免不小心出现锁漏洞,发生未保护访问。但是,继承和多态,特别是再加上protected和友元,是类成员变量,成员函数的“视界”(看得懂这个词不?就是一个成员函数能看见,访问的变量范围),成员变量的被访问域,都模糊不清,这在多线程开发中极其造成bug。
      所以我回避使用。我没觉得我这么说有bug,我也写了20几年程序了,起码,不这么用,我也赚到饭钱了。
      
        
        - P.102 第2段「用聚合不用重载」,但从内文推理作者应该是指不要用承继(inheritance)。
        
      这个我读着俱乐部有讲,是笔误,应该是“用聚合不用继承”,下次印刷修改
      
        - 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基本无用。
        
        - P.118-119 对头文件依赖问题错误描述。 Forward declaration 只能声明一个型别的存在,所以只能使用其型别的pointer或reference,而在例子中用A a是不行的。一个header #inlclude 另一个header是很正常的做法。
        
      这个就是吹毛求疵了,这个A a,我想说明的是另外的问题,你非要说不符合,我也没办法,我书中那么多符合的你不说,非要跳出一句话,我不是讲这个意思的例子,来说明,我实在无话可说,只能说你是恶意断章取义了。
      
        - P.126 说不需要用 ++i 只需要用 i++。在C++ 里是建议相反的,因为物件的post increment/decrement operator是需要额外的copy construction。
      
      ++i和i++见仁见智,本来就都可以,C++可以建议++i,我当然也可以建议i++啊,凭啥C++放个P都是香的,我这里写一点自己的看法就是大逆不道?
      
      因此,你这里提出的所有问题,我均不认为是问题,拒绝修改(除了那个笔误啊)。
      
      
      
      
      
    2010-01-26 15:08:15 肖舸
      根据你对本书的评论,我也点评你一句:
      “形而上学”
      你是香港人,可能没有上过大陆政治经济学的课程,可能不一定懂这个词,可以请教一下你身边的大陆朋友。
      有一点请关注,我这里使用,不是褒义。
    2010-01-26 15:14:05 肖舸
      咦,居然还漏了一句,这里补充回答。
      
      - 书中很多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++标准的代码都改过来,这才会用?
      如果你这么做,猜猜老板会怎么对你?夸你?还是炒了你?
      
    2010-01-26 15:35:08 肖舸
      嗯,最后还有一句话,我对你身份有怀疑。
      除非,你能举出本书后面几章的例子来。
      什么原因,我不想讲,但是,如果我讲了,某些人可能会很没有面子。
      我提示,有人是有我前面几章的电子稿的。
      目前,网上,china-pub,豆瓣,以及其他几个地方,我发现几个ID批评我的风格,批评我书的要点,很雷同,嗯,你此处还好,多了几个关键点。
      我不好判断这是不是某一个人,或者一群人的马甲号,一个人说话,写文章,整体风格是恒定的,批评的时候,是针对书里面的bug,帮助作者做得更好,还是针对作者本人,其实我们大家看起来,都一目了然。
      我呢,仅仅是现在觉得还没有必要,有必要的话,我会发博文来讨论这件事情。
      如果你想撇清你自己呢,请到本书的后几章找找bug,那我就信你。
    2010-01-26 20:29:43 Binny
      @书作者 :
      Are you kidding? 0 bug impossible!
      看到你的书名,我怀疑你的这本书不是写给程序员看的,而是写给软件推销员看到吧?
    2010-01-26 20:35:32 halida
      个人感觉以上的一些讨论很多是项目相关的。甚至没有一个定论,有没有错我不知道,因为我C++不熟,不了解具体的实现。
      我知道一点:现在的程序开发,依赖的东西太多了,编程语言,编译器,操作系统,库函数,设备驱动,CPUcache和指令集优化,甚至还有语言本身内置数据结构比如浮点,整型的限制,内存收集机制等等。
      程序员几乎如履薄冰,每一步都要小心犯错(不靠谱的程序员除外),这个时候,程序员的个人修养和开发规范成为我们的保护伞,防止我们迈进bug的深渊。
      书我没有看过,但是感觉楼上的讨论有点偏,尤其是肖舸,最好不要用人身指代的词汇,把问题局限在技术上面。这样也可以说是讨论的原则,防止我们迈进“论战”的深渊。
    2010-01-26 20:37:18 halida
      用统计的话说:
      软件不可能没有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 halida
      可能是肖舸刚出了书,意气风发中接受不了批评吧,语气激烈了些,milo消消气,大家把重心放在技术上,不要在无谓的地方浪费时间。
      作者应该感到高兴,因为有那么多人来帮助指导你提高。哈哈。
      知道这样,等我以后把python用熟后写本0bug python编程。然后等口水雨吧。。
    2010-01-26 21:00:48 肖舸
      呵呵,群P啊。
      你们凶。
      请你也耐心读一遍我的回应。
      如果理解不了呢,再作几年程序再来理解吧。
      起码,我现在每天还在做程序,嗯,老板还没有炒我,Mantis上,还暂时没有我的bug。
      不是说任何一个读者跑过来说我哪点错了,我就无条件修改的,我还有我自己的判断呢。
      怎么着,逼着我改错了,好再骂?
    2010-01-26 21:03:31 halida
      可能是肖舸刚出了书,意气风发中接受不了批评吧,语气激烈了些,milo消消气,大家把重心放在技术上,不要在无谓的地方浪费时间。
      作者应该感到高兴,因为有那么多人来帮助指导你提高。哈哈。
      知道这样,等我以后把python用熟后写本0bug python编程。然后等口水雨吧。。
    2010-01-26 21:08:32 halida
      不管技术上面到底怎么样(我也看不出来),
      但从语气上,肖舸没有腔调。。。
      我还是离开这里吧。
    2010-01-26 21:09:43 肖舸
      IT界怎么出了你们这帮东西?
      个个有能耐,都做点实事去,在这里骂人不算本事的。
      肖某人人品怎么样,自有公论,起码,CSDN学生大本营,大家没有瞎了眼,还认我这号人物。
      我说句话,各位,有哪个有胆子报真名出来PK的,我就和他好好讲话,否则,一概认为马甲号。
      嗯,你们那个google的group,我知道,网址在这里,http://groups.google.de/group/pongba/browse_thread/thread/99471c9d14322d05/9397699bff277d98?show_docid=9397699bff277d98,仅仅是我没有加入,没有和各位发言而已。
      各位也是读书之人,躲人背后说长论短,羞也不羞?
      
    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:14:48 肖舸
      那就麻烦你帮我重写,你都懂完了,麻烦自己写书。
    2010-01-26 21:15:27 肖舸
      顺便问问,你写过多线程开发没有?
    2010-01-26 21:15:50 halida
      谁骂你了?在讨论问题哪。
      
      “IT界怎么出了你们这帮东西? ”
      这是典型的人身攻击,我脸皮厚无所谓,
      只是你平时也会这样说话吗?你看见那个牛人会这样骂人吗?
    2010-01-26 21:17:11 肖舸
      请问攻击你哪个部位了?
      请问你哪个部位是东西?
    2010-01-26 21:19:00 肖舸
      朋友来了有美酒,XX来了,有猎枪的。
      我牛不牛,确实不知道,只有大家说了算,不过,要说PK吗,以前也干过。还行,本事没搁下。
      什么玩意儿!
    2010-01-26 21:20:36 肖舸
      一个二个纸上谈兵,我也说句狂妄点的话,各位写代码有没有写过0bug的?写过的,请留下来,我们继续讨论,互相学习。
      没写过的,麻烦就不要评论了。
    2010-01-26 21:21:44 halida
      上面访问时间的问题,我虽然不是科班出身,原先看csapp也有一定了解,
      看arm结构也知道了一点,
      就是时钟信号是拿来同步用的,而取得的数据有可能是放在cache里面,有可能miss掉,再从内存里面取(硬件实现),
      不过书中原文没有看过,不知道是不是说这个问题?因为看不到上下文。
    2010-01-26 21:24:35 halida
      上面访问时间的问题,我虽然不是科班出身,原先看csapp也有一定了解,
      看arm结构也知道了一点,
      就是时钟信号是拿来同步用的,而取得的数据有可能是放在cache里面,有可能miss掉,再从内存里面取(硬件实现),
      不过书中原文没有看过,不知道是不是说这个问题?因为看不到上下文。
    2010-01-26 21:24:58 肖舸
      报实名!
      无名无真相!
    2010-01-26 21:25:38 肖舸
      嗯,你们那个google的group,我知道,网址在这里,http://groups.google.de/group/pongba/browse_thread/thread/99471c9d14322d05/9397699bff277d98?show_docid=9397699bff277d98,仅仅是我没有加入,没有和各位发言而已。
        各位也是读书之人,躲人背后说长论短,羞也不羞?
      
    2010-01-26 21:28:58 halida
      邮箱多少?我把列表转发给你。
    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:37:11 肖舸
      算了,我也拷贝一点你们背后的评论,都是从那个google的group拷贝来的,也让大家看看你们是一群什么东西。
      -先写一本书,然后转向培训行业,忽悠更多的年轻人入行,是程序员转行的另一条路子,嗯.
      -这个人已经是个培训老师了;好多学生亲切的称之为老师。。。。。。 但是话说回来,传播错误的知识比什么也不做的确更有危害;这个界限很多时候难以道明的
      -恩,按照你这个评论,那么0bug,或者1bug的梦想,作者肯定是达不到了,呵呵
      -最终产品卖到钱了,才能算作0 bug,这句话已经说明了,作者对0 bug标准定得很低,“大家”心目中的标准更低
      -我没有看过这本书。作者说是为了避免内存碎片而对代码作了特殊的处理,不知这本书中是否有讲避免内存碎片的技术。如果C++有诸多累赘实在干不了这活,用纯C不 也行么,为何一定要再套一层C++呢?
      -看来作者已经有点不耐烦了,我好不容易写本书,怎么你们不好好学,都来骂我这里写错了那里写错了,都是我的仇人穿了马甲来害我的吧。。。
      -看了,笑了,同时也傻了——真有这么不要脸的人啊??? 照他这样搞咱们许多人都应该等身了
      -我躺着的话,等身有点难
      -从这一点上说,肖舸 作为作者说的实在有些过分了。 可以辩论道理,人身攻击就没意思了, 这书没买,幸哉!
      -作者没有腔调。更没有肚皮。
      -在书店看过几章,没买,基本上也知道说些什么了. 书中的做法有些山寨,我第一次看到有人拿自己的ID之类的作为类名的一部分的. 另外,看这本书的时候我看见他实现的那些组件:内存池,log之类的就想到了C\C++程序员喜欢自己重新造轮子.
      -我说的是肚皮的尺寸…唉,施主你怎么又想歪了…
    2010-01-26 21:40:55 Milo
          - P. 86 「由于C 和C++ 语言,标签在编译时一般都具有全局性,因此,一定不能重名......」标签只需要在一函数内不重名就可以,goto 也只可以使用同一函数里的标签。那种全域命名方式是没需要的。
        
      >  不管全局标签有没有必要,我从命名上规范标签具备全局唯一性,效果只会更好,是不是这样?请问有没有问题?
      
      效果是否更好,這是見人見智的。我說出的錯處是「由于C 和C++ 语言,标签在编译时一般都具有全局性,因此,一定不能重名......」
      
      這是對 C/C++ 語言對標簽理解的錯誤。
    2010-01-26 21:41:28 halida
      这样的评论很正常啊。。。
      
    2010-01-26 21:41:35 肖舸
      有一件事情,还是请大家知道一点。
      我压根没打算进培训业,我在网上做老师,全部免费。我免费给西安程序员俱乐部做演讲,我还自己掏腰包,请摄影师拍下来,免费发给全中国的大学生看。
      我唯一赚钱的事情,就是写了这么一本书,出版社要卖钱的。
      当然,各位还可以说我神经不正常,好自我YY,这些我认。
      
      肖某人人品怎么样,请围观者看看我的博文。
      http://student.csdn.net/space.php?uid=39028&do=blog&view=me
      
      我凭这些博文,CSDN学生俱乐部人气最高的老师,CSDN博客专家博客,51CTO博客之星,我确实不信,全中国只有你们几位老大“独醒”!
      
      你们牛哈。
      
    2010-01-26 21:43:46 肖舸
      骂人不难的,难的是做点事情出来让别人骂!
      不过说实话,各位骂人还真没点创意。
      你们有骂的更狠的同胞的。欢迎围观哈。
      请各位到这个网址参观,嗯,对了,建议从头看。
      http://www.china-pub.com/member/bookpinglun/viewpinglun.asp?id=196191
    2010-01-26 21:44:40 肖舸
      嗯,前面没有PK痛快,我这里最后,正式回骂各位一句:
      一群鸟人!
    2010-01-26 21:45:02 halida
      「由于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 halida
      个人总结几个问题:
      肖舸你觉得被骂了,所以你愤怒是不是?先说我认为应该怎么回应。
      说有问题的,回应解。说有错误的,回应讨论。人身攻击的,不回复。
      如果你觉得我们是鸟人,你应该证明我们是鸟人。。比如我们有翅膀之类。。。这才是正统的回应。
      骂人是没有建设性的。
    2010-01-26 21:54:25 肖舸
      呵呵,继续。。。
    2010-01-26 22:00:42 肖舸
      那位香港人,如果你真心是想讨论书的技术问题,请翻到书的最后一页,里面有我建议的读者俱乐部地址,只要到读者俱乐部好好发帖,我们慢慢讨论,没有问题。
      但是,在这里以写书评,试图影响我书的声誉和形象呢,我可真不接受。
      万事讲方式方法,我已经给出了良好的建议,你不遵守,乱来,我也只有不客气了。
      嗯,还有一个,这些网上马甲号众多,你不报实名,也确实不要怪我把你当马甲号狂拍。
      感觉你不是在讨论技术,一个是想吹嘘你自己,“你看,我比作者都牛”,另一个呢,就不知道什么目的了,也许真是马甲号也说不定。
      我还是那句话,读者和作者交流,讲个诚信,报实名,我们慢慢谈,可以,但是乱来的话,就只有不好意思了。
      
    2010-01-26 22:00:54 halida
      刚才写了一下,果然, statement和expression的概念是不同的。。。
    2010-01-26 22:04:51 halida
      试图影响我书的声誉和形象。。。。
      拜托,书评区就是用来影响书的声誉和形象的呀。
      如果你觉得有书评不合适的话,找管理员删帖就好了呀。
      我知道你要卖书,所以关注书评,希望大家捧的多。
      但是人们怎么说,你还要控制,和GCD有什么区别?
    2010-01-26 22:04:56 andy
      哈哈..终于把号注册好了,我本来想说,肖老师,你鸟他们搞毛啊..自会有你的书的读者来抱不平的..我是不行了,因为我太菜鸟了..
      不过,你有一句我很同意...把名字报出来!!
      然后再PK...
      名字都不敢说的..算什么英雄.人家乔峰到哪儿不是说自己叫乔峰..
      
    2010-01-26 22:05:52 [此人已被删除]
      从twitter上看到这篇评论,进来看了一下。建议halida和Milo不要再说了,因为看得出来作者不够冷静,还不能理性的接受别人的批评,都散散吧。
    2010-01-26 22:05:59 肖舸
      这位萧萧同学,别做出那幅样子好不好?
      这封帖子是谁发的?
      谁在google的group中号召大家过来围观?
      可都不是我。
      说自言自语,大家请去这个group里面围观一下,看什么叫做YY。
      http://groups.google.de/group/pongba/browse_thread/thread/99471c9d14322d05/9397699bff277d98?show_docid=9397699bff277d98
      骂人不带脏字,我也会,不过,就是觉得没多大意思而已。
      说狠一点,就是骂人都不敢骂痛快了,怕报复。
      嗯,身上缺某种零件的男银。。。
    2010-01-26 22:06:46 andy
      你们敢报名字么.......其实他们说肖大你..你应该感到高兴啊..我就是JAY的粉丝..我就看到很多人损JAY为什么呢.因为他红啊..他火啊...为什么他们骂你呢...你红呗..你在学生大本营里.人气这么高.......
    2010-01-26 22:08:14 肖舸
      其实我一直怀疑这个香港同胞到底买书没有?
      网上什么都有可能是假的。
      读者俱乐部就在书最后印着呢,他居然不知道。
      很可能是某位马甲号。
      现在的Windows系统输入法,输入点繁体字本来就不难,大家就用简体拼音就可以输入,因此,不能说自己是香港人就是香港人了。
      
    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 halida
        从twitter上看到这篇评论,进来看了一下。建议halida和Milo不要再说了,因为看得出来作者不够冷静,还不能理性的接受别人的批评,都散散吧。
      +1
      
      其实我是好玩,在这里做培训,以后会在生活中想办法让人变专业些,平时练练。
    2010-01-26 22:10:40 andy
      在古代,战场上.英雄们一般都说一句.挑战者.报上名来.吾不杀无名之辈...
    2010-01-26 22:10:40 肖舸
      这就是写书的悲哀啊。
      躲暗处骂人,射暗箭,说实话成本太低了,已经被用来作为曲解民意的手段了。
      嗯,我还怀疑,这几个号,统统背后坐着一个人呢。
      嗯,也许是某个小网吧里面的小团伙呗。
      中国现在有很多所谓的网络公司专门做这个的。就是收黑钱拍人。
      我原来不知道,是电子出版社的编辑建议我了解一下,我才知道这个网络这么黑暗。
      嗯,andy别说了,小心别人说你是我的马甲号哦,呵呵。
    2010-01-26 22:14:04 肖舸
      嗯,对头
      名都不敢报,说什么专业IT人士。
      呵呵,专业的网吧黑打手差不多。
      就说讨论哪些问题,哪个涉及到本书最核心的并行开发?
      我就从来没发现哪个人从内存池往后,找到bug的。
      几个原因:
      1、真没bug,说实话我不信,因为已经有人找出笔误了。
      2、骂人者水平不够,我看基本上还属于刚出来的大学生水平,还停留在书本就是圣旨的地步。
      3、就是我前面说的,有人只拿了我前面几章,在那里攻击呢。这个呢,有利益之争,我已经通过出版社去解决那个人了。
    2010-01-26 22:14:19 halida
      我是无名之辈,没有写过什么东西的,有名号的人一般没有时间来战的。
      真名什么的建议大家不要到处说,现在是敏感的时候,说了真名对生存不利。
      但是假名还是靠谱的,网名没有变过。以后也不会变,要么是机械唯物主义,要么是halida。
      还有就是,真名有什么重要的?都在网络上混,做出的东西也是挂假名,可以相当于古代的字号了。
    2010-01-26 22:15:57 肖舸
      出来混,不敢报真名,就要有被别人当马甲号拍的觉悟!
    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:10 肖舸
      香港人,别YY了,你再长篇大论,我也不看。
      看看我前面的回复。
      
    2010-01-26 22:18:12 halida
      攻击有可能,出版界可能很黑暗,我不是这块的不了解。
      大学生应该指我,我没有进过商用程序的项目,可以说是大学生级别的。不过我没有骂人,只是在这里顶骂名。(好吧,我说过一句没腔调没肚皮)
      书没看,我也不评,我只是围观书评。
      
    2010-01-26 22:19:22 肖舸
      那就麻烦闭嘴,免得误伤。
    2010-01-26 22:23:52 halida
      Milo说的还是很靠谱的。。。类访问机制是拿来做抽象的。。和具体实现的功能是不影响的,是否可以这样理解?
      这些抽象都是防君子不防小人。
    2010-01-26 22:30:11 Dbger
      本来想发表几句,看到最后变成口水战了(一个人的口水),甚是失望
    2010-01-26 22:31:25 肖舸
      网络上1拍n我又不是没拍过,99年就干过了,呵呵,还可以,多年的本事没有落下。
    2010-01-26 22:32:30 肖舸
      还有,失望就麻烦走远一点,回家里躲被子里面慢慢失望去。别在这里碍眼。
      
    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 Fleurer
      路过,仅围观
    2010-01-26 22:38:21 肖舸
      欢迎围观,路过的不送。
    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:42:12 肖舸
      百无一用是愤青!
    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:12:56 肖舸
      这位大师,一群人PK,是不是只有我一个人有错?
      大家都对完了?
      作者只能挨骂?
      如果豆瓣网办成这样,我这个作者,还真不敢让我的书上来评论了。
      整个一个找骂嘛。
      其实像你这种敲边鼓的,明眼人一眼就看得出来的。
      看似公正,其实说话帮强势一方的。
      大家可以看看,今天这个帖子里,我是不是弱势群体。
      找小弟我也会啊,我还一堆学生呢,我只是觉得不好而已。让学生尽量别参与。
      这类群P,见多了。
      
    2010-01-26 23:14:11 肖舸
      像你们这群只能骂人,不能被骂的,最多也就一群愤青而已。
      不是说到twrite上开个论坛,讨论讨论问题就高雅了。
      
    2010-01-26 23:15:33 肖舸
      出来混,要拍人,就要有被拍的觉悟!
      连实名都不敢报的人,其实充其量一群小人而已。
      
    2010-01-26 23:16:54 肖舸
      还有,香港人不值钱的,香港脚倒是要花钱治疗。
      我还天天和台湾朋友聊我的书呢,他们怎么没找到这么多所谓的bug?
      这香港人还真是懂完了。
      还是那句话,你今天说的所有问题,除了我承认的一处笔误,其他我本人认为都不是bug。
      拒绝修改。
      自己YY去吧。
    2010-01-26 23:17:37 Milo
      2010-01-26 21:00:48 肖舸
      >  请你也耐心读一遍我的回应。
      >  如果理解不了呢,再作几年程序再来理解吧。
      >  起码,我现在每天还在做程序,嗯,老板还没有炒我,Mantis上,还暂时没有我的bug。
      >  不是说任何一个读者跑过来说我哪点错了,我就无条件修改的,我还有我自己的判断呢。
      >  怎么着,逼着我改错了,好再骂?
      
      我很耐心讀完你的回應,我覺得我已經理解了,也很耐心地回應你的回應。
      
      當然作者看到讀者的回應,應該會細心思考,可能之後再以討論(包括該讀者及其他人)的形式冒求改善。
      
      我怎麼逼你了。更沒有駡。
    2010-01-26 23:21:23 肖舸
      算了,不说了。
      难的你这么好心,找了一大堆bug。
      还是谢谢了。
      不过,很可惜,每个人看法不同,你说的这些,我这个作者认为不是bug,因此,不修改。
      恐怕你要失望了。
      如果你实在气不过,建议你自己写本书出来,写你认为正确的C++编程,我可以帮你代为联系编辑,只要书好,保证出版。
    2010-01-26 23:22:06 refactor
      其实我倒不在乎作者0bug的说法,只要书确实能对我有帮助就行。
      今天这篇评论我从头看到尾了,高下立判,评论者的严谨让人佩服,作者的胸襟嘛,其实无所谓,看书又不是看人。还好,庆幸当日没在书店冲动买下。
    2010-01-26 23:22:55 肖舸
      我也谢谢你没买,要不,又多个骂的。
      
    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:23:42 肖舸
      那就麻烦做点7*24的server,再讨论我书中的问题。
      不是说会写client,就会写server的。
      
    2010-01-26 23:25:42 肖舸
      我的server在公网上正跑着呢,两年了,运维部门一个bug都没有报。这算不算0bug?
      里面用的全部是这本书里面的知识。
      我倒奇怪了,计算机都承认,你不承认?
      我一直有个感觉,还好我在IT业,起码,判断知识对错有个标准,计算机是最公平的。代码好不好,敲出来一run就知道,不需要人来判断的。
      这要是其他什么行业,出本书被人这么骂,还不得冤死?
      
    2010-01-26 23:27:09 老猫
      Milo不要浪费时间了,比起在这里苦口婆心循循善诱,还有很多更有意义的事情可以做,比如逛街吃饭等等。
    2010-01-26 23:27:15 肖舸
      我倒不知道你是做什么行业的,但是,我只能说你对工程的理解,很弱。
      起码在我们公司,不敢请你做程序的。
      我公司的服务网站:www.freepp.com.cn
      去下个client来run,注册个id,当你能正常登陆打电话的时候,记住,后台我的server就在为你服务,我书中的知识,就在为你服务。
      
    2010-01-26 23:28:26 肖舸
      我想,书里面东东对不对,这个最有发言权。
      嗯,其他那些敲边鼓的,就麻烦闭嘴了。
      这位香港人,好歹还看过我的书。
      你们这帮人呢,书都没看过,就开骂,累不累啊?
      
    2010-01-26 23:28:45 SpitFire
      大家洗洗睡吧,这本书已经没啥好评论了
    2010-01-26 23:30:01 肖舸
      一帮子愤青,天天骂中国如何如何落后,结果,别人做点不一样的东东出来,马上骂。比学究还学究。
      你们的group里面,自己人都说自己劣根了,看来是真的。
    2010-01-26 23:32:30 eating
      有意思
    2010-01-26 23:34:59 肖舸
      确实有意思。
      有帮人不累。
    2010-01-26 23:35:23 Jeffrey Zhao
      嗯,不错,围观。
      肖老师好,我来曝实名了,我的博客是 http://www.cnblogs.com/JeffreyZhao/ ,我会继续关注这贴的。
    2010-01-26 23:36:27 肖舸
      我倒也很想看看,有没有打抱不平,能出来为我这个作者说句话的。
      中国那么多愤青,按概率都应该一半对一半啊。
      怎么这个帖子里面,大家一边倒?
      奇怪,好像有组织一样。。。

  • Fi

    2010-01-27 09:55:54 Fi (那是一小块凝集的时间)

    看不懂

  • 丁丁虫

    2010-01-27 10:03:15 丁丁虫 (最喜欢涅妹子了~)

    身为IT党,一定要去留个名!

  • 炸馒头片儿

    2010-01-27 10:04:48 炸馒头片儿 ((读)纯粹理性批判 66%)

    有个自我感觉良好的C++程序员写了本书,号称按他的教导可以0bug开发。然后有人好意的很认真点评了一下,他自尊心受损,死活认定写书评的人是来踢馆的,其实人家那个书评人是牛得不得了的大牛,单纯想好心指点一下。于是引来了一大群圈儿内的牛人围观,吵了三页。早上作者居然删帖了……

  • 小护士毒舌猫-虞兮虞兮奈若何

    2010-01-27 10:09:47 小护士毒舌猫-虞兮虞兮奈若何 (膝盖中箭庆元旦)

    你备份晚了,谷歌大神都说没有这回事了。

  • 小护士毒舌猫-虞兮虞兮奈若何

    2010-01-27 10:10:30 小护士毒舌猫-虞兮虞兮奈若何 (膝盖中箭庆元旦)

    不能得罪圈里人呀。

  • 炸馒头片儿
  • 丁丁虫

    2010-01-27 10:16:49 丁丁虫 (最喜欢涅妹子了~)

    蘑菇蜀黍您这一招就有点损了……做个PDF不是更好吗……

  • 炸馒头片儿

    2010-01-27 10:19:43 炸馒头片儿 ((读)纯粹理性批判 66%)

    呃,我错了……我去找找文字版

  • 头疼星人

    2010-01-27 10:20:46 头疼星人 (振奋!)

    所以呢,姿态一定要低。。。所谓伸手不打笑脸人嘛

  • 小护士毒舌猫-虞兮虞兮奈若何

    2010-01-27 10:24:31 小护士毒舌猫-虞兮虞兮奈若何 (膝盖中箭庆元旦)

    我无语了,it人就是无耻,居然打包了。。。

  • 账号停用。

    2010-01-27 10:24:34 账号停用。 (已经无槽可吐)

    被人骂了就知道比喻别人是马甲。当然了,我们鉴定他是马甲,这个在修辞上是拟人。

  • 安庆卢十四

    2010-01-27 10:47:58 安庆卢十四 (高帅富)

    非程序员见到热闹看不懂,抓心挠肝ing。。。

  • ishmael

    2010-01-27 11:03:15 ishmael (青霄終有路,唯恐不堅心~)

    求pdf或者txt下载慢慢看
    好像上回谁在pythoncn还是toplanguage上已经谈过这本书了吧?
    感觉这个作者是在慢慢顶不住批评的压力在逐渐崩溃过程中……

    其实我觉得中国的IT业界写书也是在慢慢摸索的过程中
    真正写的好书得要一版版慢慢修炼出来啊

  • 妲拉

    2010-01-27 12:31:05 妲拉 (可有可无的人类)

    哈哈哈卢十四同学我不是IT人也看懂这热闹了呀!
    技术不要看,看骂人看回复态度就OK了……

  • Fornever

    2010-01-27 12:45:15 Fornever (无聊的人生要和有趣的人共度)

    居然和作者差不多时候加入此组,我觉得灵魂收到荡涤了……

  • 猛禽

    2010-01-27 14:03:26 猛禽 (三无大叔,飞面教徒,死萝莉控)

    唉,我昨天也可耻滴去围观了那个作者。囧

  • 嘎嘎

    2010-01-27 16:03:41 嘎嘎

    会用0bug当标题就说明这作者rp不怎么样

  • 贾里

    2010-01-28 01:25:57 贾里 (各种习惯养成闭关期间)

    作者其实比较牛,但是遇到神牛受不了了。。哈哈哈

  • 2010-01-28 04:34:10 [已注销]

    就像我成功搅入了不管什么热闹的时候一样,那个作者当时一定是打了鸡血似的兴奋...

  • 炸馒头片儿

    2010-01-28 13:32:36 炸馒头片儿 ((读)纯粹理性批判 66%)


    2010-01-28 01:25:57 贾里 (朝圣之路)

    作者其实比较牛,但是遇到神牛受不了了。。哈哈哈

    ====================

    刚开始我也以为是个牛人,但是读了这篇文我深感作者就是个二百五

    http://student.csdn.net/space.php?uid=39028&do=blog&id=21604

    办公桌前抬眼望去,同事里比他牛逼几个层次的不知道多少去了。

  • maluguos

    2010-01-29 00:19:26 maluguos (啃书,扫CD,折腾每一天)

    这人嘴脸不是一般丑陋,开始打鸡血般谩骂,一觉醒来药效退去,发觉牛皮吹破了再抵挡不住,开始删帖删ID。
    问题是这也就作罢了,这跳梁小丑偏偏还自以为做得多么干净,于是就有这么一篇意淫无比的自白书:http://blog.csdn.net/tonyxiaohome/archive/2010/01/28/5265573.aspx

  • 丁丁虫

    2010-01-29 00:29:39 丁丁虫 (最喜欢涅妹子了~)

    蘑菇蜀黍给的链接比较雷人……

  • 小护士毒舌猫-虞兮虞兮奈若何

    2010-01-29 08:31:17 小护士毒舌猫-虞兮虞兮奈若何 (膝盖中箭庆元旦)

    蘑菇叔叔给链接也不说明一下亮点,看不懂呀

  • 头疼星人

    2010-01-29 08:38:02 头疼星人 (振奋!)

    把mcse列在自我介绍里。。。这也太狗血了吧。。。

    其实吧,他要是换个书名,叫什么一名老程序员的心得与体会之类的,前言后记里写点儿什么一家之言冷暖自取各位老师请批评指正的话,估计大家也没那么大兴趣砸他了

  • 小护士毒舌猫-虞兮虞兮奈若何

    2010-01-29 09:34:16 小护士毒舌猫-虞兮虞兮奈若何 (膝盖中箭庆元旦)

    发现一个笑点

    网名:东楼

    请自行google

  • 炸馒头片儿

    2010-01-29 13:40:32 炸馒头片儿 ((读)纯粹理性批判 66%)


    2010-01-29 08:31:17 小护士毒舌猫-虞兮虞兮奈若何 (既视的更年期)

    蘑菇叔叔给链接也不说明一下亮点,看不懂呀
    =====================================
    说来话长,可比满清大员初见蒸汽船无风自行,以为牛拉……

  • 2010-02-02 12:43:20 冰隼

    围观啊。

  • 存在感

    2010-02-03 12:43:43 存在感

    作为一名未来挨踢从业者我承认我看不懂...

  • 炸馒头片儿

    2010-02-09 09:51:31 炸馒头片儿 ((读)纯粹理性批判 66%)

    热闹主角来我那儿友好访问鸟,欢迎围观

    http://blog.csdn.net/ccat/archive/2010/02/07/5295931.aspx

  • 静水沉岩

    2010-02-09 09:57:13 静水沉岩 (全金属狂潮第三卷)

    csdn blog专家,蘑菇叔好牛

  • 静水沉岩

    2010-02-09 10:02:07 静水沉岩 (全金属狂潮第三卷)

    csdn的评论居然用opera看不了,只能用ie看。

  • 炸馒头片儿

    2010-02-09 10:08:40 炸馒头片儿 ((读)纯粹理性批判 66%)

    那个专家……并不难得到啊……很多人都有……

  • 四不象

    2010-02-09 10:52:54 四不象 (←著名歪脖)

    出书骗钱,混口饭吃,你砸人家饭碗,人家当然要拼命了,哈哈

  • 春琴

    2010-02-09 12:37:05 春琴 (诸法皆字)

    http://hi.csdn.net/space-66219-do-feed-view-me.html
    他好鸡东地到处找别人文章回呢



这个小组的看客也喜欢去  · · · · · ·

耶稣爱你妹.
耶稣爱你妹. (922)
科幻世界
科幻世界 (32727)
拜亲王教
拜亲王教 (1395)
双.峰.驼
双.峰.驼 (1945)
天地正道≋ὥ≋飞面神教
天地正道≋ὥ≋飞面... (2589)
World War II
World War II (2181)