[132期] 實戰乃王道：C/C++開發常見bug解析
程序員是個很辛苦的職業，通常面臨無窮無盡的加班，但經過分析發現，大多數加班并不是因為項目時間不夠，而是前期開發沒有設計好，后期出現了無法跟蹤，甚至無法解決的bug，導致研發時間不可控，這就是通常所說的"bug是加班之源"。因此，我們如果能在設計階段，預防、暴露很多bug，將大大減輕程序員的壓力，使開發工作變得很愉快！
技術門診是51CTO社區品牌欄目，每周邀請一位客座專家，為廣大技術網友解答疑問。從熱門技術到前沿知識，從技術答疑到職業規劃。每期一個主題，站在最新最熱的技術前沿為你引航！
本期技術門診我們邀請到軟件研發和管理領域專家、IT圖書作者肖舸專家與大家討論C/C++開發中的常見bug的解決方法。
本期專家：肖舸
擅長領域：C/C++，商用數據傳輸
專家簡介：普羅通信（西安）有限公司研發主任，MCSE，商用程序員。擁有多年的軟件研發和研發管理經驗。精通C/C++，TCP/IP，擅長分布式數據庫、服務器集群以及并行計算領域的研發。曾擔任西南交大客座講師，講授《C/C++語言無錯化程序設計》課程。曾在多家企業擔任項目經理，負責過的項目有《http tunnel防火墻隧道穿越系統》、《freepp V1.5 服務器集群》、《電子白板子系統》等。 著有《0 Bug ---- C/C++商用工程之道》。
查看本期門診精彩實錄：http://doctor.51cto.com/develop-144.html
參與最新技術門診：http://doctor.51cto.com/
精選本期網友提問與專家解答，以供網友學習參考。
Q：編輯程序一定要會英文嗎
A：你好，我的理解，英文不是編程必須的，但是，英文好，無疑能極大地幫助編程開發。目前，國內的計算機書籍，普遍偏于膚淺，對于很多問題的深入討論，開發人員一般習慣于看原版資料，另外，很多編程語言，平臺api的開發說明，如VC的MSDN，Linux下的man等，都是英文原版的。這些都要求開發人員具有一定的英文功力。因此，建議盡量把英文學習好一點。
Q： 肖老師，您好！ 一個困擾我很久的問題，我想問您一下：為什么creat()函數不是叫create()? 另外,O_CREAT標志為什么不叫O_CREATE? 這個算不算是一個bug？難道最初寫這個函數的人不懂英文,以致于后來大家都跟著錯,以致于像我這樣按照正確的英文寫函數名稱的人會一再的寫錯這個函數的名字?
A：我的理解，這其實是一個人性化的問題。
英語發展到今天，其實已經不完全是英國人的英文了，其實世界各地的人們在使用英文過程中，其實都在按照自己本民族，本文化的習慣在修改英文。比如"顏色"這個詞，colour，但是美國人嫌麻煩，就是不想寫那個u，因此，慢慢地，這個詞被修改為"color"了，最后英文本身也不得不認可這種修改。這中間例子還很多，比如"PK"，比如"VS"，都是人們在使用過程中，對英文的修訂。這說明了語言一個很重要的特性，沒有權威，用得人多了，自然就成了權威。
因此，學習英文要注意"方言"，前段時間說中國人將會為英文貢獻一些中國式英語，我覺得不難理解，也無可厚非，反正大多數人都這么用的話，就是對的。
你說的問題，可以理解為程序員的一種方言，程序員是很喜歡用縮寫的，并且不是很講究自然語法，開發英文更是不會去管時態等修飾變化，這些都是程序員特點，如果大家約定俗成，這么寫也是無所謂，反正寫的人和看得人都明白就好了。
不過，我個人還是喜歡使用create。呵呵。
Q：肖老師，您好！我想請教一個問題：
C++寫插件報錯，請問這個是bug么？
試了下用精靈source 文件夾下的QMPluginWizard.awx做dll，調試了很久終于成功編譯成功， 結果放到plugin文件夾里面啟動按鍵，正準備進腳本看看效果的時候彈出了上面的這個錯誤。開始還以為是我的函數問題，最后實在找不出錯誤，就不添加任何函數生成了一個原始的DLL ，結果一樣報錯=.=
請問這個問題是怎么回事呢……
A：sorry，你這個問題問得沒頭沒尾的，我無法回答。
請問你在為什么系統寫插件？PhotoShop，FireFox等很多軟件，都有各自的插件體系，我不清楚你在寫什么插件。簡單說一點，插件就是軟件的原始開發者自己定義一套api規約，允許后來的程序員使用這個api規約，開發屬于自己的軟件模塊，原系統可以根據這個api規約予以調用，實現系統的擴容。因此，這首先是一個私有協議系統，不懂的人，水平再高也不會開發，因為它的定義都很隨意，是原始程序員拍腦門的結果，另外呢，有一定規范性，必須按照人家約定的api規約來，不能有一點錯誤，否則就失敗。建議你好好看看原始文檔，體會需要提供的每一個api接口的特性，這樣才能開發出正確的插件。
Q：肖老師您好！
軟件測試的主要目的在于發現軟件存在的錯誤(Bug)，對于如何處理測試中發現的錯誤，將直接影響到測試的效果。只有正確、迅速、準確地處理這些錯誤，才能消除軟件錯誤，保證要發布的軟件符合需求設計的目標。在實際軟件測試過程中，對于每個Bug都要經過測試、確認、修復、驗證等的管理過程，這是軟件測試的重要環節。相對來說，bug的管理也顯得很重要了。
您能簡單闡述一下Bug管理的一般流程嗎？
A：我的理解，只要是軟件企業，bug管理是必須的。bug管理抽象出來，是一個管理流程，和程序其實沒有多大關系，而是公司里面有這么一套管理"人"的機制，以便對bug實行跟蹤，落實到人頭去解決。一般說來，公司內網應該安裝一套bug管理系統，我們公司用的是Mantis，這是一個開源產品，很好用，根據權限，QA檢查出bug，即提交到這個系統上，PM根據情況，指派給某個RD解決，解決后，RD回復已解決，并修改狀態，QA做回歸驗證，最終實現一個閉環。我的理解，一般的測試人員，找到bug并不難，難的是如何精確描述bug，通常，QA對于bug的產生情況描述越精確，RD越能快速定位，快速解決。但這需要經驗，不是每個人都能做到的。因此，我通常建議，bug的管理和解決，應該RD和QA共同努力，而不僅僅是測試部門的問題。我在開發中強調白盒測試，即RD寫完每個模塊，交稿時都要附有該模塊的測試工程，這些測試代碼不會最終release出去，但是，可以幫助PM和QA做初步的分模塊驗證，其實只要有這個驗證過程，很多bug可以在RD提交代碼之前解決的。
我的新書《0 Bug ---- C/C++商用工程之道》，其實主要就是一本RD寫給RD的書籍，幫助RD養成良好的開發習慣，理解很多開發中細節的差異性，以便寫出bug盡可能少的程序。這本身，就是試圖從源頭解決bug問題，降低后期QA的工作強度。
Q：系統2003，VC6.0編譯時經常性死掉，只能結束任務，重新開啟VC是不是有毛病呀？還是由于是盜版呀？
A：VS2003是一個中間版本，微軟自己都承認有很多bug，建議換用VS2008。VC6.0還是比較穩定的，我用它開發過n個商用工程，應該問題不大。
關鍵是，如果你的程序中大量調用系統內核的資源，如共享內存區，鎖，線程等機制，稍微控制不好，是可能把操作系統本身掛死的，因此，這個問題還是要反過來查找程序，如果程序中有bug，這就不是系統的毛病了，需要你作為程序員修改bug。我的新書《0 Bug ---- C/C++商用工程之道》，里面有幾章著重論述了多任務開發中，內核訪問的核心技術，如鎖、內存、線程、任務等調度算法，并且給出了一個可用的工程庫樣例，建議書出來看一看，可以對操作系統內核的工作有個初步的理解。
Q：肖專家：
保存工具條菜單有 bug 嗎？使用浮動菜單條時，SaveBarState 和 LoadBarState 出現了問題。如果菜單是浮動的，重起應用程序時它會出現在左上角，而它固定在屏幕其它位置時，下一次啟動就會出現在該位置，這是什么原因？
A：這個浮動工具條我用的比較少。嗯，初步分析，這個ocx控件有一定的自我狀態存儲機制，即退出時會保留自己當前的位置到注冊表，下次啟動后讀入，并重新定位。如果你不想它自己保留，其實也很容易，簡單說就是自己每次啟動程序，主動用程序設置一下工具條的狀態，把它放到你想放的地方就好了。
Q：肖老師,你好,可能提出的問題與這期主題不相關,自學C++有一段時間了.最近很迷茫,總感覺,知識很混亂,連不上來,而且自己一下覺的失去了目標,學了C++應該往哪一方面發展.如果自己是想向游戲這方面發展,應該如何走下去,以及在網上看到了有關游戲腳本語言,有些或惑,不太了解.
A：一般說來，寫游戲還是需要用C和C++的，因為游戲講究速度，腳本語言很難滿足需求。如果你希望做游戲，現在的游戲公司一般都是網游居多，而且，游戲是典型的并行程序，對于多任務開發能力要求很高。建議看看DirectX開發相關書籍，嗯，我的書也可以看看，可以幫助提升多任務開發能力。
有機會的話，可以到游戲公司實習一下，就能更具體地了解需求了。
Q：肖老師您好：
我是一名剛剛學習C++的學生，我有幾個問題想請教您，內容可能與本期主題無關。現在C++與JAVA語言，哪一個有更好的前途與"錢途"？學習完C++的語法知識后，還應該學一些什么呢？比如說是MFC之類的？對這個很迷茫！除了《C++編程思想》以外，還應該讀一些什么好書呢？謝謝！
A：C++和Java很難說誰好誰壞，二者分別針對不同的領域。Java可能對于數據庫應用，企業辦公應用更合適一些，C++和C呢，則針對底層開發，高性能開發比較擅長。比如大型游戲，高性能服務器，嵌入式系統底層驅動等。我的理解，二者如果鉆進去，都可以獲得很好的錢途，不過，得鉆才行。
我的博客中有幾篇，對你可能有幫助，建議你看看。
關于Java轉C++方向問題：
http://tonyxiaohome.blog.51cto.com/925273/198777
簡述C和C++的學習歷程：
http://tonyxiaohome.blog.51cto.com/925273/198753
關于C和C++找工作的討論：
http://tonyxiaohome.blog.51cto.com/925273/198750
另外，如果你已經學習完C++的基本語法，建議看看我的新書《0 Bug ---- C/C++商用工程之道》，對于你迅速掌握C和C++開發的實戰技巧，從學生走向程序員很有幫助。
Q：我剛學完C語言程序設計，要學C++，什么都不清楚，到底什么是bug，聽說bug很嚴重，到底有多嚴重？聽說編譯環境也會影響程序的bug多少，是嗎？到什么時候才應該注意bug，編寫多大的程序才用的著查找bug？
A：bug是一種程序界的說法，其實就是指程序中的錯誤啦。理論上講，任何程序都有錯誤，原因很簡單，程序是人寫的，是人就一定可能犯錯誤，這些錯誤，可能是簡單的一個筆誤，也可能是比較嚴重的邏輯歧義，邏輯沖突等，最終的結果都是一樣，就是程序無法獲得希望的設計結果。
其次，每個程序都有其應用范圍，如果超出范圍使用，也可能造成bug。比如我們設計一個服務器，預設為并發100用戶服務，當并發用戶增加到1000人時，就可能因為服務器太繁忙，而無法完成服務，這也是也是bug的一種。因此，bug是一個統稱，其實包含了軟件開發中各種各樣的問題，只要不能達到或滿足我們的設計要求，都可以算作bug。就程序而言，bug并不嚴重，因為只要bug暴露出來，程序員一般都有解決辦法。嚴重的是商業程序涉及很多商務合同，有按期交工的時間底線，超過時限就罰款，甚至取消合同，這和錢有關系，就比較嚴重了。而如果不幸，我們發現軟件運行有問題，并且bug找不到，就很嚴重了，程序員大量的加班都來自于此，并不是老板狠，而是商務合同快到期了，不拼命不行。因此，作為公司里面的商用開發來說，bug，特別是無法查找的bug，確實很嚴重。
理論上，軟件研發的任何環節都有可能存在bug，不僅僅是代碼實施階段，在系統設計階段，也可能存在bug，這往往會給軟件后期的測試帶來"硬傷"，而這種"硬傷"，成本往往很高昂。我親身經歷過的，就有由于系統基礎庫選型出現問題，最后軟件工程差點失敗，公司浪費人民幣接近200萬元的事情。因此，在軟件研發的各個階段，均應高度關注bug，再小的程序，也應該高度關注bug。商業程序員對很多bug要做到能預防，并且在軟件開發中設置很多機制，幫助bug自行暴露，降低程序員查找bug的成本。
#p#我的新書《0 Bug ---- C/C++商用工程之道》，里面詳細介紹了我解決bug的方案《C/C++無錯化程序設計方法》，其實這種方法并不是讓程序真的沒有bug，而是用很多習慣的養成，用很多統計、測量的方法，用程序幫助bug自動暴露出來，以便第一時間獲得解決。因此，如果你以后希望開發高性能，高強度的商用程序，建議看看我的書，以后的程序開發工作，bug會比較少。
Q：c++與c有什么區別啊？
A： C++是面向對象開發，OO，C則是面向過程開發，OP。二者不同主要體現在開發思維上，所謂對象，就是一些數據，以及這些數據相關方法的組合，因此，C++的開發思想，主要體現在以數據為核心，并為數據搭配方法，而C的面向過程，則是以方法為核心，數據是方法處理的對象。
舉個例子，我們把一個箱子搬上樓，C的說法，搬是一個方法，可以把箱子這個數據丟進去執行動作，最后出來的程序就是"搬（箱子）"，而C++箱子是數據主題，搬是這個數據的方法，因此其說法變成了"箱子.搬（）"。不過，二者其實區別也不是很大，C++畢竟脫胎于C，語法什么的都很接近，而且，即使是面向對象的C++，也是由一個個方法函數組成的，在每個函數內部，其實還是用面向過程的方法來寫程序，因此，我一直有句話，學好C++，最好先學會C。就是這個道理。在我的新書《0 Bug ---- C/C++商用工程之道》里面，上述概念有更加詳細的描述。另外，里面體現出來的實用化的開發思維，其實沒有顯式區分C和C++的概念，反而故意在混用二者進行開發，主要就是在解決實際工程問題時，隨著各種問題的不同，有的適合用面向對象，有的適合用面向過程，單用哪種其實都不太好，合用最好用。因此，建議初學者不要太刻意去區分二者差異性，都學習一點比較好。
Q：你好，我是一個c++的初學者，我正在看的是《c++ primer》，請問你對初學者有什么建議？或者好的經驗傳授一下，謝謝。
A： 其實我的理解，《c++ primer》這本書挺好的，應該仔細看，多看，方能理解其中真意。當然，這本書主要是講解C++本質，內核的一些東東，對于應用實戰貼合不是很密切，因此，對于修煉內功。很有幫助，但是對于實戰招式來說，還有所不足。我寫過很多對初學者的建議，都在我的博客中，有興趣的話，建議看看我博客的文章。http://tonyxiaohome.blog.51cto.com/ 另外，我的新書主要就是針對C和C++的實戰做講解，并進一步升華為原則和思想，建議等書出來，買本看看，會有好處的。
Q：肖老師，我在運行一段簡單的代碼的時候，出現了預想之外的結果：
1 /************************************************
2 * squares -- Print the squares of the numbers *
3 * from 1 to 5. *
4 ************************************************/
5 #include
6
7 int main()
8 {
9 // An array for the squares
10 int array[5];
11
12 int i; // Index into the array
13
14 for (i = 1; i <= 5; ++i) {
15 array[i] = i*i;
16 }
17
18 for (i = 1; i <= 5; ++i) {
19 std::cout << i << " squared is " <<
20 array[i] << '\n';
21 }
22 return (0);
23 }
請問，這種情況如何解釋？這樣的是程序設計中的bug嗎？
A： 這段程序顯然會崩潰的。
C和C++語言，都有個特點，就是數組的計數器是從0~n-1的，比如你的例子，int array[5];，則有效的數組單元是0，1，2，3，4，而你的循環體是從1~5，到最后一個數組時，已經超出了數組的界限，你去訪問array[5]了，而這塊內存顯然不是分配給你的，你又做了賦值動作，相當于強行向一塊不屬于你的內存寫入數據，因此，程序很可能因此而崩潰。
這是一個很重要的細節，在我的新書《0 Bug ---- C/C++商用工程之道》中，有一章專門講解C和C++語言的無錯化程序設計方法，中間特別有一節專門講到了這個問題。即如何寫for語句。標準的建議是：for(i=0;i C和C++無錯化程序設計方法，是通過一系列標準動作，標準寫法，規避絕大多數常見bug的方法，建議書出來后看一看，這類問題以后就再也不會困擾你了。 Q：那么對于一個初學程序的人來說是 先學C語言好呢，還是先學VB 呢？或是其他語言！數據結構怎么學起啊？ A： 我覺得任何語言都可以入門，并且經過深入學習后，都可望成為大師。 C語言呢偏向底層，VB語言呢偏向Windows應用開發，特別是針對互聯網和數據庫方面，比較方便。看你自己的愛好和方向了。其他語言有Java，PHP，看看目前的語言排行榜，其實排前幾位的就這幾種，都可以學習的。數據結構則請跟著大學教材學習吧，這些知識比較死，也沒什么發揮余地，教科書就是最好的參考書了。 Q：ntp技術是什么啊？ A：NTP協議全稱網絡時間協議（Network Time Procotol）。它的目的是在國際互聯網上傳遞統一、標準的時間。具體的實現方案是在網絡上指定若干時鐘源網站，為用戶提供授時服務，并且這些網站間應該能夠相互比對，提高準確度。 NTP最早是由美國Delaware大學的Mills教授設計實現的，從1982件最初提出到現在已發展了將近20年，2001年最新的NTPv4精確度已經達到了200毫秒。 Q：您好，請問您，如何在設計階段預防無效的不必要的加班，從而減輕程序員的壓力！謝謝您！ A： 你的這個問題有點"大"，不是一句兩句話能說清楚的。我們知道，軟件應對的應用場合很多，不同的項目類型，側重點各有不同，因此，很難有一個通理能解決所有的問題。簡單說的話，我的理解，系統設計有個問題必須要解決，就是回答好"市場要什么"和"我們能做什么"這兩個問題之間的矛盾。 我們知道，尺有所短，寸有所長，任何一個公司的研發部門，任何一個高手程序員，都不敢說，自己的知識領域，能夠覆蓋所有的應用需求，因此，每次當市場需求反饋到研發部門，我們都需要做個評估，到底能完成哪些部分。這并不丟人，而是一種務實的解決問題的態度。因此，公司的系統設計師，其實應該善于把握平衡，并不是市場說的都對，也不是研發說的就一定做不到，而是在市場和研發之間維持一種平衡，針對市場需求，為研發設置一個稍微高一點的目標，跳一下就能夠到，不是研發天天躺在過去的成績上睡大覺，這樣做的產品肯定沒法賣，也不應該怎么跳都夠不到，研發逼死都做不出來，那最終還是市場沒有可賣的產品。 其實這對系統架構師，設計師這個角度來說，要求非常高，既要有敏銳的市場分析能力，能對市場需求去偽存真，提取那些可做到的，成本本公司能承受，市場上又確實有突出賣點的功能點來做，又要對本公司研發團隊能力有很詳細的了解，知道研發的底線在哪里，不會一味討好市場和老板，設置一些根本不可能達成的目標。現代企業中，一般不是一個人做這件事，而是幾個專家組成工作組來共同完成，他們小范圍的PK，能極大節約公司市場部和研發部之間的大量溝通成本。 另外，在項目管理的各個關鍵點，設置里程碑，實施各級評審也能較好地解決上述矛盾。很多公司為了解決上述矛盾，甚至專門開預研類項目，來對某個新技術做預研和技術儲備，以便更好地指導下一步的研發工作。上述細節看似和研發沒有關系，但可以看出，如果上述工作做好了，關鍵技術點都有了成熟解決方案，并且，產品路線圖做得很合理，一步步地前進，則可望做到設計階段預防無效的，不必要的加班，從而減輕程序員的壓力。當然，這個問題是一個系統工程，需要全公司從機構設置，工作流程安排上作出努力，才可望做到。 作為程序員呢，其實也可以在其中做一點工作，我們知道，一個公司做的事情，主要還是針對有限的幾個方面，不同的產品和項目，技術上總得來說還是有傳承性，比如做路由器的廠商，可能在嵌入式系統底層的一些模塊有技術積累，而做網游的廠商，則對圖形處理部分肯定有積累。程序員我認為有責任把這種積累變成"工程庫"，每次新技術的開發，都盡快以工程庫的形式沉淀下來，才能避免二次重復開發，并且，經過長期積淀的工程庫，往往經過了多個工程的測試驗證，性能很穩定，bug很少甚至沒有，這樣新工程依托這些成熟穩定的工程庫，就可望快速成型，且質量穩定，由此也會避免程序員大量無謂的加班找bug的過程。 并且，工程庫的整理和維護，也可以使系統分析員對本公司技術實力有個更加清晰的認識，對于未來項目設計更加具有合理性，因此，從這個意義上說，即使是剛剛加入公司的程序員，對于系統設計的仍然是有互動作用的，就是及時總結和歸納自己已經做過的程序段落，及時形成自己的工程庫，并爭取納入公司級的工程庫做一體化維護，這才是軟件開發中，減少bug，降低開發勞動量，避免無謂加班的終極解決之道。 我的新書《0 Bug ---- C/C++商用工程之道》，主要目的就是站在商用工程開發的角度，幫助大家建立工程庫思想，并提供一個初步的多線程安全工程庫供大家使用。因此，這本書對于你的問題有很大的幫助，建議等11月份書出來后，買本來參考。 【編輯推薦】
