當東樓撞上西門

當東樓撞上西門

1       “野路子”程序員寫的山寨C++的書... 1

2       值得翻閱的地方和不足... 1

3       0bug的賣弄... 2

4       書中的瑕疵和bug. 2

5       別把自己太當回事... 5

 

本人聲明,本文的目的就是幫肖先生炒作,以及騙取點擊數量,旗幟鮮明參與罵戰。但點穴就要點到點子上,一次足夠了,沒興趣對戰,當然我也給肖先生機會罵回來。

1               “野路子”程序員寫的山寨C++的書

本來很早買了這本書《0 bug——C/C++商用工程之道》,大概因爲china-pub上推薦(最後買於dangdangchina-pub發貨太慢,擔心過年收不到),也不知道是否是當時論戰導致的推薦。但第一眼沒有吸引我,所以先放在了一邊。

上上上上上週六無意瀏覽到了CSDN一貼,大約看完了兩邊的精彩論戰,看着挺逗的,於是熬夜用2天初讀了肖先生的書。最後我把部分評價貼給了肖先生,結果當然還是刪貼,既然肖先生和我不是同道中人,他有刪貼的權利,我也有言論的自由和發帖的地方。我骨子裏也是一個好湊熱鬧騙點擊率的人。所以乾脆幹到底,完整的寫出書評來,幫肖先生炒作一下。

 

看完書的感覺是,肖先生強烈質疑的評價,“強烈建議初學者不要買這本書,以免被毒害。這是一位“野路子”程序員寫的山寨C++書。”還是非常中肯的,因爲本書不嚴謹(甚至可以說非常不嚴謹),這種不嚴謹會非常嚴重的傷害新手,但是作爲反面,老手拿來反芻還可以,因爲很多地方老手會會心一笑。野路子和山寨都不是貶義,位字更是尊稱了,本書也的確不是學術類型的書籍。這個無比準確的評價,卻被肖先生列爲罪證,有點可笑也有點可悲。

2               值得翻閱的地方和不足

本着厚道的原則,還是先寫值得翻閱的地方,本書的是一個老程序員的總結,雖然我認爲作者其實多餘OOC++的理解都有很多瑕疵,但作者畢竟是一個有總結的,在編程規範,debug,統計方式輔助調試,跨平臺,安全編程,有過總結。有些觀點是可以看看。比如作者文章中間沒有涉及無鎖技術,但是已經在考慮無鎖的優勢。有比如作者對爲什麼要用線程,總結混亂,但在任務池一節已經開始考慮使用狀態機的方式避免過多的線程導致不必要的線程消耗;“行爲鎖”和“資源鎖”的比較;設計之中也已經開始考慮。作者的一些總結之話也有精彩的地方,比如如果你的程序寫的不夠簡單,就已經寫錯了,“一個好的習慣,解決整整一個方面的bug”。

本書最大問題是打着C/C++的旗號,本書卻很難體現其在OO設計,泛型編程,設計模式方面有什麼造詣,說是0Bug,但是書中不嚴謹和錯誤地方,涉及了跨平臺,但是卻對操作系統知識卻有很多誤解,列舉了很多編程準則,卻有很多觀點經不起推敲。另外,書的排版和章節設置問題也很多。佔據大量篇幅的789章節裏面的設計,以及實例代碼很難談得上值得閱讀。

3               0bug的賣弄

我聲明我不反對這個標題,寫書不是標題黨也難。但是我反對的是肖先生關於他自己工程中間0bug的炫耀式的舉例,比如15萬行的代碼,最後發現的bug纔多少個。其中C/C++纔多少個。這種統計,純屬大忽悠,代碼的質量是看測試的bug數量是和代碼修改量比較纔有實際意義。如果你有15W行代碼,上個版本測試通過,這個版本改動200行,測試出10多個bug,那是丟臉的事情。不值得炫耀。

另外,肖先生關於的他代碼bug統計方法也有意思。70%是內存的bug。我其實挺好奇的,就是初級菜鳥的bug也不會70%問題是內存問題吧,真不知道肖先生開發的業務邏輯是不是都是i++類型的。或者說肖先生的bug極少,所以我等常人無法理解。

小弟財蔬學淺,和肖先生一樣從事c++後臺開發多年,代碼也有完整的框架和重用庫,會限制其他開發人員直接參與內存管理,每次提交測試後,每百行修改bug數量大約在0.5-0.8個之間。平常只有5%bug大約和內存相關,大部分的都是業務邏輯,功能性bug。所以羞愧一下,和人家差距太遠。

4               書中的瑕疵和bug

學術用詞這個東西,衝突很多,但起碼有兩個東西要明確,一是尊重傳統,二是如果有差異,也請請明細列出來,侯捷先生在這方面由於臺灣口語衝突問題,曾被國內少數讀者質疑過,其實侯先生對於歧義的名詞都有對照表,真算是不錯的楷模。而看完本文我才發現,肖先生的在學術用詞上發明創造能力纔是驚人的。

                                                                                                                                                    表1 肖先生的發明學術名詞

發明的詞彙

頁數

調侃

遠堆調用

P28

無非是用堆作爲參數傳遞的方式。。。。

NPI

P55

問題是肖先生還是缺乏戰鬥精神,爲啥沒有FPI,文件讀寫APIMPI,內存讀寫API出來呢。

多讀單寫鎖

P241

steven書的可能會有點鬱悶。。。。

“靜態”數組

P330

本文很多地方都用了靜態這個詞彙,但是如果你千萬不要和static想到一塊了。

死線程

P428

第一次聽說這個概念,不知道作者是如何創造的這個東西

 

 

 

 

爲什麼我說這本書,完全不合適新手讀呢,因爲肖先生是在寫blog(也可能是寫bug),不是在寫書,寫書就必須照顧你的讀者,要假設他的知識背景,如果你寫給初學者看,你就要涉及背景,對每個細節把握,而且不能在某個主題過於深入。如果你寫學術或者教育書籍,就一定要把所有的講清環境,甚至版本,以及來龍去脈。這既是所謂嚴謹。其實國人寫書嚴謹的也的確不多。也是國人的一個問題。(當然國人也不是沒有寫書高人,去年的《程序員自我修養》就非常不錯。)

0 bug——C/C++商用工程之道》在嚴謹這個問題上的態度是,他是出來打醬油的。

                                                                                                                                                       表2 書中間不嚴謹的地方

原文

頁數

調侃

32位操作系統,通常把內存分成兩個2GB的空間,每個應用最大可以使用2GB私有空間

Linux(浮動棧)一般是10MB                

P26

P98

如果先生只在Windows下幹活,我也就不廢話,偏偏先生高舉着跨平臺大旗。

後來看到默認棧大小,我估計肖先生大約是在RedHat下幹活的。

線程總數有限制,Linux下一般一個進程爲300條左右。

P33

先生爲何不說說爲啥是300呢,是不清楚還是不知道Linxu有一個ulimit指令。不過好在有個一般做形容詞糊弄。

另外我奇怪的是先生的前面說他使用的系統棧大小10M,用戶空間默認2G。不是在不理解先生怎麼能有300個左右?

COM技術的本質還是實現跨進程的通信而實現自動傳參

P71

如果肖先生在COM前加個D還有說的過去。

嚴禁變量轉義

P90

這兒明顯不是我們常說的轉義。而是多義

處理跨平臺設計需求,建議儘量不要使用模板,繼承,虛函數等C++高階特性

P103

自己不懂這些高階特性可以理解,不要打着跨平臺的旗號說。。。如果肖先生有興趣,去看看ACE的庫。

不要使用兩個以上的*

P141

開始我也以爲肖先生修煉有道。甚至可以不用scanf類似的函數。

看到下面發現先生同意用&*,我奇怪的是***&的區別是?

嚴禁使用指針參與四則運算

P142

不知道肖先生指的四則運算時哪四個,我很想看看肖先生用指針如何做乘除運算。

不安全的sprintf,還是不安全的_snprintf

P164

snprintf的問題建議大家還是看看網上對於各個平臺這個函數的說明。

這個函數(vsnprintf)完全體現了我們的分析結論,即嚴格的防禦性設計,構造100%安全的C語言字符串

P183

稍微有點常識的就知道printf類型的函數是是無法保證類型安全

請大家不要奢望在LINUX下可以自如的使用中文,所有的中文字符原則上都會顯示成亂碼。

P551

其實我強烈頂打印到屏幕上不要出現中文,但是Linux好歹也是一個操作系統,用不着這樣小瞧他把。

發現32Linux下一個文件的最大一般2GB

P507

一開始莫非先生的Linux使用FAT16文件系統,後來想了想肖先生可能在Redhat下幹活,明白了。但是……,肖先生應該百度一下,這個2GB的大小限制是可以調整的。

……

 

 

文中肖先生的錯誤觀念:

                                                                                                                                                             表3 文中的錯誤觀念

原文

頁數

調侃

統一使用基於TCP/IP協議的socket作爲進程間通信手段

P39

如果世界真那麼簡單,寫操作系統的人倒是可以輕鬆和下崗了。

Windows檢查重複枷鎖的漏洞

P45

這不是操作系統不嚴謹,而是作者的不嚴謹,請理解鎖的概念。另外用信號燈代替一下MUTEX,或者請讀一下ACE的實現。

筆者一個函數名稱有237個字符

P80

這個事情自己看就可以,說出來容易嚇唬大家。

只使用publicprivate定義,

用聚合不用重載

P102

第一個觀點體現了作者的OO水平,

第二個觀點除了不用這個觀點偏激以外,文章內部說的好像是多重繼承。

很多時候,VC這個編譯器有一些怪癖,比較突出的就是stdafx.h這個預處理文件。

……

但一定要叫stdafx.h

P119

人家微軟爲了加快你的編譯速度,好不容易實現了預編譯頭文件,你不知道如何用也就算了,取消不了還怪人家微軟。難道肖老師連VC++工程文件都沒仔細看看嗎。

Makefile的簡單寫法

P120

這一章都充滿着對Mafile的誤讀。。。肖先生寫的那個Makefile真談不爽簡單。其實看了這一節。我很懷疑肖先生的工程在如何進行編譯管理的。。。

單寫多讀鎖

P241

對於這個讀寫鎖的效率我保持很大的懷疑。由於這個讀寫鎖的設計中讀和寫的操作實際使用中要多次使用互斥量。效果可想而知。

一般說來,線程啓動時間間隔250ms會比較安全,低於這個間隔,則很可能導致“死線程”的出現。

P428

我不嚴謹的認爲,這99.999%是臆斷或者肖先生的程序存在什麼bug。從來沒有什麼文檔反饋WindowsLinux平臺下的線程有這個毛病。

……

 

 

 

 

5               別把自己太當回事

最後說說另外2個事情。 一是別懷疑別人的動機。二是別把自己太當回事。

當然說了也白說,人家聽不進去。或又肖先生已經進化到吧自己當鳳姐了,此次粗口開罵也只是出名的一個機會,只是我等遲鈍之人看不出來。

鑑於是國人自己的書,而且也有很多心血,野路子有時候對於解決問題的好方法,,我對此書打3星。但仍然不推薦新手購買。非常不建議。

最後還是建議肖老師別再叫東樓,這個字被人用過,而且用過的人……有典故了,於是有了上面的標題。肖老師大概加班太多,沒時間閱讀了,建議休息的時候看看《明朝那些事》。

 

最近折騰一點私事,本來打算3月初寫完的東西,結果4月初都沒有寫完,本來想撤了,看東樓肖先生那邊還挺起勁,又再折騰了一天寫完。

 

【本文作者是fullsail(雁渡寒潭),本着自由的精神,你可以在無盈利的情況完整轉載此文檔,轉載時請附上BLOG鏈接:http://blog.csdn.net/fullsail,否則每字一元不講價。】

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章