第一篇：一個C++程序員的學習經歷

正在上網的時候有這個念頭的，所以急急忙忙找了一些學習編程的高人的感想：

我開始學VC時就是自己一個人在啃，也沒什么人指導，當時沒有條件上網，資料特別少，在書店里隨便買本書就學了，在學VC的過程中走了許多彎路，現在回想起來覺得做了很多無用功。看見大家在這里暢所欲言，有高手也有新入門的ddmm，我也來談談學VC的一點“捷徑”吧，這條“捷徑”純粹走的是C/C++的路子，不考慮學習其他語言。（我只會C/C++，略懂VB和Java，所以對于通過其他語言來切入VC的沒有體驗，不置評論）

1.必須對C/C++非常熟悉

如果C不熟，可以看清華譚浩強的書，經典之作。（學習時間1到2個月，對函數、指針和鏈表須滾瓜爛熟）

如果C++不熟，可以看電子工業出版社的《面向對象的程序設計于C++教程》，張國鋒寫的，既講面向對象的思想又講C++的語法，是我見過的講C++最全最好的書，里面的例子都是精心設計的，值得好好體會。好像清華也出過一本張國鋒的，不過我沒看過。（學習時間2到4個月，關鍵在于理解OO概念和C++中的多態，對此應揮灑自如）

2.最好/應該對Windows結構相當熟悉。

如果你很牛，非要從MFC下手來了解Windows結構，當然也不是不可以，但我以為從MFC來學習Windows有霧里看花的感覺，很容易陷入迷惘中，我吃過這種苦頭，希望后來者不要走這條路。

如果對Windows結構不熟，可以看Microsoft Press的Windosw95 Programing，清華翻譯出版了中譯本《Windows95程序設計》，后來北大翻譯出版了最新的版本。清華版的譯得不錯，北大版的沒看過，好壞不知道。這本書講的是怎么樣用C語言編寫Windows程序，不講什么MFC或OWL的，看過后對Windows能有相當清晰的認識。（學習時間3~6個月，GUI對象和消息很熟，多線程、dll有一定認識）

3.以上兩部為準備工作，OK后就可以continue學習VC了。

學VC看Microsoft Press的《Inside Visual C++》清華翻譯出版了中譯本《Visual C++技術內幕（第四版）》比較容易上手，看《技術內幕》一定要看清華，有一本希望出版社翻譯出版的第五版技術內幕翻譯的太爛了，看希望的不如直接看英文原版。（學習時間4到7個月）

4.學習VC是為了在Windows平臺下做開發，所以當你對一上三步都很熟后應該進一步深入學習Windows體系才能開發出高性能的Windows程序，你也只有在這個時候才會明白為什么說VC是真正程序員用的工具而VB只是玩具。如果你在finish第三步之后已經忘記怎樣在Windows下用C語言編寫一個Windows程序，那么你應該把第2步Refresh一下。在這一層次應該深入研究Windows操作系統內的進程、線程、虛擬內存等知識，還應該了解Windows網絡程序的設計。這一步推薦的書是Microsoft Press的《Advanced Windows》清華翻譯出版了此書的中譯本《Windows高級程序設計（第三版）》，讀此書時很多東西有相見恨晚的感覺。機械工業出版社翻譯出版的《Windows核心編程》是這本書的第四版，結構上重新組織過了，內容沒有細看過，應該還可以。網絡編程有一本也是MicrosoftPress的，好像是叫《Windows Network Program》吧，機械工業出版社翻譯出版了此書的中譯本《Windows網絡編程》還不錯的。

5.往后你就看自己需要了，有興趣可以學習COM/DCOM/COM+，這套東西是現在Windows系統的核心架構。

用VC學VC兩年了，自認為不是什么高手，精通更談不上了，因為VC的功能實在太強大了。我只想談一談自己的學習過程和體會，總結一下自己的編程之路。

一開始也和大家一樣，對VC、VB、DELPHI、JAVA非常感興趣，但是學什么好呢？畢業設計來了，導師要求要么用VB要么用VC，聽說VC難學但很有用，于是狠狠心用VC吧。對于一個對編程一點都不感興趣的人我想他是學不好的，沒有強烈的動力和恒心也很難掌握一門知識。怎么辦呢？你總要畢業吧，這就是我的驅動力，而且編程還可以掙錢：），學吧！

對于一個一點都不懂的人來說，下面的知識應該補一補：程序算法和數據結構，C語言的變量、數組、指針、內存、文件、函數等等基本概念和用法，有的人說學c++可以不用學c，我個人認為還是從C學起好，因為c＋＋對c是兼容的。

有了最根本的編程基礎之后，我們就可以學習c＋＋的編程思想，就是面向對象（oo），自然對于什么是類、對象、成員、成員函數、構造函數、析構函數、虛函數、模板，最開始可能用不上析構函數虛函數什么的，但要想精通深入就必須掌握（當然可以以后再學）。可以說面向對象是c＋＋對c的一個最重要的擴展，而這也恰恰是我們理解和深入的基礎，這部分越扎實以后理解和掌握就越快。

再下來就是MFC了，MFC是一個很好的封裝類庫，它誠如大家所說對用戶屏蔽了很多實現機制，以致很多人只知其所以然，而不知其然。要想知其所以然，當然是學習windows編程，熟悉windows的消息、窗口、api函數。可惜當初我只是為了快，沒有深入地學，留下了現在地惡果，對MFC及其機制仍不甚明了。一則MFC已經封裝好了，二則自己覺得麻煩和累，一大堆長長的函數名和長長的函數參數把我嚇暈了，大家千萬不要學我^-^。基本觀點就是如果只求使用，不學api也可以，如果想做得更好精通，非學不可。對于MFC，對我幫助最大是www.tmdps.cn、程序員大本營、和MSDN，有了這三大法寶加上自己的刻苦鉆研，一定可以成為大蝦。前提是有一定的英文基礎，并且已經知道如MFC frame及application的基本運行機制，對對話框、編輯框、組合框、列表框、進度條、標簽.......等控件的基本功能都自己試過。我就是從這些開始學習MFC的，另外還學了一些和數據庫打叫道的東東，如ODBC之類的，我覺得如果僅僅是界面開發，這些東西還是可以勝任的，都是些簡單易學的在哪里設置什么屬性，添加變量和調用成員函數就行了，不笨的人都會，當然如果你不知道在哪里加又會變得很神秘和難于上青天，夸張了呵呵。這時候你就要查書問別人上internet和幫助網站去找了，具體成員函數的用法可以看MSDN。總之對于沒有學api耿耿于懷，對于沒有了解MFC機制也愧疚于心，因此把自己歸于初級水平還是可以的：

VC是一個開發工具和環境，在你需要的時候你可以邊學邊用。比如你要編網絡方面的東東，好！先去看看別人是怎么做的，有哪些基礎，另外你自己也要針對需求學一些網絡知識。微軟的主頁還是不錯的，英文好的話可以找到很多很好的東東。你要編關于數據庫的程序，請先了解一下數據庫的基本概念和它們在VC中的使用。你可能還有各種各樣的編程需求，如游戲、小程序、動態連接庫、靜態連接庫，COM,ActiveX等等，學習吧，這是唯一的捷徑。我的體會是，邊學邊用，邊用邊學。學習先打好一定的基礎，磨刀不誤砍柴功，看似浪費時間實則受益匪淺。學習要利用一切可以利用的資源，書（包括電子的，不過我很少看電子版本）、BBS、網站（比如VChelp）和高手，勤學好問，搜索不倦，想必你肯定也會成為高手的：）。書我是狂看、亂看、瞎看，主要是沒有條件和時間，當時也沒人指點應該看那一本好書，原則就是找到自己需要的東西的書就可以拿來翻一番（當然我有圖書館這個資源，學生借本書應該沒有問題的）。BBS主要去精華區溜達溜達，里面都會有你要問的一般性問題，如果實在找不到答案，請去codeguru，微軟網站和MSDN查找搜索，應該可以找到蛛絲馬跡。這樣還是很費精，如果有高手指點就不一樣了，他們做過的話，這可能就是小差一疊，隨便說一個關鍵詞就可以幫了你的大忙，可惜高手畢竟是少數，正好碰上做過的高手的概率就更小了。所以各式各樣的網站就顯得那么的重要，它們一天二十四小時都在，而且可能是很多高手都在，因此在它們身上可以找到一些參考答案。問專家我覺得不錯，VChelp更全面和包羅萬象。說了這么多，都是自己的胡思亂想了，一點個人體會，不當之處，各位多多批評指正了*^-^*

下面是我的一些建議,如有不對,請批評指正.謝謝!我想現在大部分的初學者都在問,怎么樣學C/C++最快?確實,這是個比較重要的問題,但對于初學者來說,最重要的,是你對學習C/C++的恒心!學習C/C++并不容易,我想這是每個初學者很清楚的事情.之所以選中C/C++是因為它的涉及面廣,并且強大.但自學想很快掌握C/C++編程那是不太可能的,除非你是個天才,或有專家專門對你進行輔導.如果學習方法和路線正確,的確可以提升學習的速度和效率.下面是我對怎樣學習C/C++的一些看法.總共分三步.第一步.系統的學習C/C++語言,(不要涉及MFC.)并且學習操作系統,對操作系統的運作有清楚的概念.這一階段,可以把重心放到研究算法上.(估計時間將會是一年.如果有人幫助的話,可能會減短.)第二步.開始學習MFC,并選擇發展的方向.一個程序員,很難做到各方面的編程技術都精通,所以要有選擇的學習你感興趣或有錢途的技術發展.如果做游戲,則可放棄對于MFC的學習,因為游戲不需要MFC.(估計時間將會是半年.)第三步.開始對各種技術的涉及.因為本人還沒有考慮到這一步,所以,不做多提,但如果你已經學到了這一步,也不用我再廢話了.(時間未定.)當然,以上的時間估計,是在假設你努力學習的情況下定的,并不具有實際意義.對于書籍的選擇,有很多人想用電子書.我提議,如果是初學,最好不要用電子書,來學習.還有些初學者對于編程工具不知如何選擇.我想無論是C或者是C++,VC都是一種不錯的選擇.如果機器配制不高,可以使用版本低的VC.VC1.52版本是個不錯的選擇.我在工作中，接觸到印度軟件公司開發出來的軟件：整個體系架構非常清晰，按照我們的要求實現了全部功能，而且相當穩定。但是打開具體的代碼一看，拖沓冗長，水平不咋樣。我們自己的一些程序員就有怪話了，說他們水平真低。

但是！印度人能夠把軟件整體把握得很好，能夠完成軟件，并得到相當好的設計文檔。而中國人在那里琢磨數據結構、算法，界面人員就還沒編碼就想著是Outlook式的還是VisualStudio式的界面。到最后就成為Code高手，對某些特定的開發工具精通，但是就是不能保證能夠把一個軟件穩當、完整的開發出來。

舉個簡單的例子：軟件中需要一個列表，用來表示我們處理的事務。該類表在業務繁忙的時候將變得很大。中國人就用雙向鏈表，抱著《數據結構》書在那里寫鏈表的類。印度人開了一個大數組，然后就開始干。為什么印度人不用鏈表，他們說：

1、你們給出的設備(小型機)，最少具備512M內存，浪費一些沒有什么。

2、數組方式訪問方便、效率高。看出了一拿到東西就吭哧吭哧作Code，和好好進行軟件分析的不同了嗎？ 正好前幾天我有幾個同事從印度回來和我們交流,那家公司是CMM4級公司.我感受的幾點:1,流程重于項目2,QC(就是QA)獨立于研發部門,專門檢查研發部門的開發流程是不是按照既定流程走.如果QC覺得流程不對,他會直接上報高層,項目定就此停止.3,所謂的項目經理(PC)一般也是從編碼人員升上來的,并不是所謂的不懂技術,一般都至少有四年以上的經驗4,PC主要就是制定開發計劃,負責協調,填寫各種表格.5,所有的東西(包括草稿)都有文檔.6,詳細文檔要求達到只有這個文檔就可以編碼的程度,一般寫文檔時間占60,編碼時間極少7,有各種詳細的review(同行評審),項目組內的,項目組之間的,客戶的...8,計劃很詳細,的確能達到小時級,但是實際情況還是誤差比較大,所以他們也有加班.先學習UML和Rose以及RU P，不要總是要找著證據。在中國的軟件開發水平下，很難給你一個好的例子，OK？中國人總是要看到一個東西有了試驗田，而且稻子長得好，才換稻種。要知道在國外上述的軟件開發模式的應用，大可以看看Rational網頁上的story。Justdoit!一句話，中國的軟件開發水平低得很。趕不上印度人，印度的軟件公司可以讓高中生編代碼，它的軟件工程水平可想而知。當然，你如果是個很牛的程序員。估計夠嗆，因為中國的氣氛中，很牛的程序員都很難接受軟件工程的。你可以測試一下自己，看看自己適不適合現在學習軟件工程：

1、你是不是不能忍受一個編程序不如你的人做你的項目經理？

2、你是不是覺得你的老板對客戶吹牛皮、夸大自己而感到不舒服?

3、你是不是一個拿到一個需求腦袋里第一念頭就是如何實現的人？

4、你是不是很崇拜Stallman，Linus，很討厭Microsoft?

5、你是不是曾經在深夜編碼的時候，突然感覺到一種乏味，對Code的生涯感到一種無趣？以管窺豹──印度神話作者：“Kino”我們現在處于深深的自卑當中，感到中國的軟件工程水平的低下已經是牽涉到民族劣根性的問題了。

1、他們的軟件教育水平：我們招聘印度人，給應聘者出了一份與國內差不多的試卷，有基礎概念和編程題目。等到他們完成后，我們這些中國的自認高手驚呆了！他們的編程題目簡直象是抄襲的?nbsp;?nbsp;程序結構，注釋，變量命名就不說了吧，全部都是極其類似！反觀中國的牛人、高手，每個人有自己的一套。到了新的崗位，先把前任的程序貶損一通，然后自己再開發更多的問題的代碼來代替。我的公司統計，一個軟件中有4個以上CSocket版本，每個人都覺得別人做得差，自己再搞一套。中國人，就是這個樣子，還會辯解說“我們這樣有創造性”。

其實軟件發展，早就走過了求伯君那個編碼英雄的年代，程序員已經是個坐辦公室的藍領了。你具備擰好一個螺絲釘的能力就可以了。Code是最低級的事情 了。

2、他們許多公司的項目經理根本就不懂技術。中國的項目經理如果不能在技術上壓服下屬，那么下屬將與他搞鬼，越是高手越喜歡搞鬼，根本不知道作軟件的終極目的是從別人兜里掏錢，而在內部搞不團結。技術高手都會糾集一些對他技術上崇拜的菜鳥，與管理層作對。而印度的軟件經理根本就不懂正在做的東西，許多甚至直接就是MBA，或者是領域專家(工業設計、地理專家等)，而不是編碼 的專家。但是卻能夠領導大群素質良好的程序員把工作做好，沒有內部不團結的情況。許多印度的程序員加入一個公司很長時間，都不知道自己整天編的代碼是干什么用的。給他們的任務可能就是一個函數的聲明以及該函數要實現的功能。我們呢？

3、他們的編程人員的流動率達到30!他們的編程人員流動率(包括內部項目之間的流動)高達30，可以想見他們的文檔水平如何。他們的產品不依賴任何一個人，誰都可以立即辭職，產品的開發還是會正常進行。而中國，是老板怕總工。技術骨干擁兵自重，抗拒管理。任何制定好的計劃，都有可能被技術人員推翻或者跟你消極怠工。

4、他們的開發計劃能夠做到小時級別。如果一個印度公司的項目經理沒有上班，那么他的下屬將可能不知道作什么。他們的計劃一般都定到天，每個基層開發人員每天的工作量就是8小時。而我們能夠給出月度計劃的 公司就很少，而給出的月度計劃要么不可能實現，要么就可能被取消。開發人員 被初略的給個任務，他在月初，可以慢慢琢磨是做成什么樣子，然后上上網，聊聊天。到了月中和月末，就開始熬夜編碼。看到每年，從各大高校不盡牛人滾滾來，我們是不得不要召人，同時又是不抱希望。我公司現在有意以后將核心軟件開發外包給印度公司，中國人？做做界面吧，中國人做界面會極盡奇技淫巧，搞得花里胡哨的。BTW，我公司非外企，大家不要誤會我們有什么種族歧視。但是我們現在就是對自己歧視，自卑得很。中科院那么多研究院，連個能用的操作系統都搞不定。北大開發一些東西，比如什么青鳥CASE，就是給一幫人評職稱的。楊芙清院士整天搞來搞去，搞出了什么東西？B大，T大的人最難管理，牛得看不見人。中國的程序員罵微軟，追Linux是全世界最狠的，可是我們除了漢化Linux，做了什么東西出來。CDE是瑞典人寫的，Linus是芬蘭的，GNome是墨西哥人寫的。哎，我們曾經是多么的瞧不起印度人。

現在，越來越多的人開始學習VC了，如果能精通VC，就象精通了九陰真經一樣，可以天下無敵了。我想很多VC愛好者都有這種追求武學至高境界的心理。

我就是抱著這種心理開始學習VC了，至今已近三年了，其間經歷過無數的困惑和磨難.....可是我最終沒有放棄，到如今已經有一定的功力 ：

以下就把我修煉中獲得的經驗與大家分享，一起提升修行！

首先要搞清楚VC能干什么.很多人只是聽說VC是最好的開發語言，便去學習，就象大家聽說辟邪劍譜厲害，便都去搶著學一樣，都是很盲目的。其實語言并沒有好壞之分，我在用C之前，一直覺的BASIC 是最好用的語言。現在在WINDOWS平臺下編程，VB和DELPHI可以滿足大多數的應用，而且速度不會很慢。使用VC主要是用來開發系統軟件和大型工具軟件以及開發游戲。現在比較流行的操作系統主要是WINDOWS系列和UNIX系列。這些操作系統都是復雜的多任務系統，在設計操作系統的時候就提供了一大堆應用編程接口（API，通常是C語言的函數），編程者使用C語言調用這些API便可以開發該系統下的應用程序了。這與DOS時代的 編程接口是不一樣的，那時侯的函數庫是由開發環境提供的（如Turbo C)，不具有很好的封裝性和設備無關性。

每當新版的WINDOWS操作系統發行，便會提供一個相應的plantform SDK(軟件開發包），開發者可以用SDK 編譯C程序。在沒有VC和VB的時候，WINDOWS程序就是用SDK編出來的。

VC跟這些亂七八糟的東西有什么關系呢？

其實VC的核心就是MFC，MFC是個C++類庫，就象結構化程序設計時代的C語言函數庫一樣，給程序員提供了豐富的編程接口，簡化了程序的設計。而MFC就是直接把WINDOWS的C語言編程接口API函數用C++的類封裝而成！這樣既實現了面向對象的編程思想，又直接使用了WINDOWS的原始編程接口，代碼的效率是 最高的！當然很多人不適應C++的編程方法，他們依然使用C語言編寫WinMain()和窗口 過程，VC同樣為他們提供了很大的便利，因為VC可以很方便的管理資源和代碼！

明白了以上關系，學習VC的步驟應該也明確了：首先要學習C語言（如果你還不會的話）！這是非常重要的。如果C語言不懂的話，一切都無從談起。懂了C語言，你就可以研究 WINDOWS系統的工作原理和WINDOWS應用程序的工作原理了。這也非常重要。VC只能用來 開發WINDOWS系列操作系統下的應用程序，如果不懂WINDOWS下的程序的工作原理就去寫WINDOWS 程序，那也是比較盲目的。主要是體會一下WINDOWS的多任務和消息驅動機制。然后就可以使用API編程了。這個過程是比較痛苦的，因為一切都變的復雜起來，你會遇到很多新的方法和概念！比如消息隊列，消息發送，窗口過程，GDI，設備上下文，句柄，線程，消息循環，繪圖對象......當你可以熟練的使用C語言進行WINDOWS程序設計了，你可以嘗試 面向對象的方法了。

這時你需要學習C++語言（最好是ANSI C++），這不是淺嘗則止，你要深入的理解C++語言的精髓！經過一定的努力，你可以用面向對象的思想去考慮問題了，這時一切都水道渠成，你可以很自然的使用MFC來編程了，有時你覺的MFC的類不好用，你可以從頭作自己的類，而不去繼承 MFC！

我每天要收到很多朋友的來信，有很大一部分朋友都詢問學習VC的方法和途徑，還有相當一些朋友對C/C++語言的前途感到擔心，總覺得學習C語言在開發效率上沒有趕上其他的開發工具，今天我就借“開發有感”這個欄目談談我的一些淺見。

首先來講我使用C/C++語言開發已經有六年多的時間了，在使用C以前我是用匯編語言的所以我轉變到C時就很自然和順利。但就目前的情況來講大家都不再需要學習匯編語言了，所以在進入C語言的世界時就會遇到一些困難這主要表現在指針的使用上。由于沒有親身的經歷所以我很難想象這個困難有多大，但我在這點上的建議就是開始時盡量避免使用指針，至于一些必須使用指針的C函數只要記住用法就可以了。當然這種情況不會持續太久，因為但你對語言的熟悉程度增加后自然也就會有使用指針進行開發的需求，那時候如果對指針的用法還沒有深刻的了解再學習也很容易，這就是主動學習與被動學習的區別。

其次很多朋友都問我如何學好VC，我想對于初學者首先應該掌握的是C/C++，VC只是C/C++的一種開發工具。如果是剛接觸C/C++則最好不要使用VC做為開發工具，因為VC的各種特性會分散你的注意力。我建議使用Turbo C++或Boland C++集成平臺做為開發工具，這兩個平臺雖然都是DOS下的但是對于初學者真是在適合不過了（當然MSC也可以）。

此外剛開始時開發一些字符界面的程序（也可以說是DOS程序，Console控制臺程序）來加深對語言的熟悉。在掌握了C/C++語言后就可以開始利用VC編寫基于Windows的窗口程序了，這時候就是一個轉折點，因為這時候Windows系統是基于消息機制的，這和單流程的程序有些區別。所以這時候也不要急著去寫學習開發和寫代碼而是應該先對Windows系統的消息機制做一些了解然后才開始學寫程序。其實我的主張是一開始用基本的SDK形式（也就是用WinMain函數的那種，不用MFC功能）來開發幾個程序做為入門，然后再使用MFC來開發程序。MFC開發的方式與SDK開發方式的最大區別就是MFC隱藏了很多細節，這是優點也是缺點對于初學者來講我認為是一個缺點，所以我建議初學者先用WinMain的形式寫程序，即使不親手寫也可以看幾個基本的程序來加深認識。

上面這些話都是為了說明一個問題“磨刀不誤砍柴工”，學習開發一定要打好基礎，還有一點就是一定要想辦法激發自己的學習積極性讓自己進入一個主動學習的境界。

下面我再分析一下C/C++與其他開發語言之間的差別，C/C++，(object)PASCAL，JAVA，PERL都是我認為比較通用而且是比較好的開發語言，但C的語法比PASCAL自由，PASCAL開發比其他結構化強，但這一點上C語言也能夠做到。至于JAVA和C++非常類似而且能夠跨平臺這一點上是很大的優勢，但JAVA開發的程序效率差。PERL也是一中我很喜歡的開發語言，雖然PERL沒有面向對象的特性（至少我認為它的面向對象很糟糕）但我喜歡PERL中自由的語法和各種時常讓人感到驚奇的用法。

如果說到Windows下的可視化開發工具現在大家接觸得最多的就是VC，VB，DELPHI，BCB，一些可視化開發的JAVA。其實我覺得VC并不能完全算是一個可視化工具，這表現在VC中編寫代碼還是占了開發工作的大部分時間。而其他的可視化工具中都在界面設計中耗費了大量的開發時間。我一直使用VC的原因就是因為我能夠一直將注意力集中在軟件功能開發上而不是界面設計上。我認為這樣能夠在開發的過程中更加自由和有更多的控制權。而且這種情況下產生的代碼維護性更強。舉個簡單的例子，在維護VB代碼時如果沒有一份詳細的說明和流程就會使維護變得不可能，我想其他的基于界面開發的工具都會或多或少的產生這樣的問題，因為在開發過程中開發工具將一個完整的流程分離成為多個部分，在開發完成后這些部分就很難統一起來。

選擇什么樣的工具的前提是你的開發目標，如果你希望開發一個很大的系統你就不應該選擇面向基于界面開發的工具，但你可能會選擇VB來開發前端的客戶軟件，而后臺使用VC來實現。

對于一些并不是很復雜的軟件來講，界面和操作方式可能是非常重要的，所以選擇VB，CBC都可以縮短開發時間。這時候選擇VC就有些不智。

所以我認為使用VC開發的朋友應該將更多的注意力集中在實現軟件功能的流程上，多從整體角度看問題。我想這一點來說其他的可視化開發工具是很難達到的，因為VB，CBC等開發的程序在很大程度上都是用各種控件“堆”出來的，這會在后期的維護升級過程中帶來很多的不便，例如要替換掉一個控件就可能會對整個程序的結構產生非常大的影響。

最后我想說的是每種開發工具都有它的價值，也各有優缺點，更重要的是如何根據具體的任務選擇合適的工具并利用這些工具來完成工作。

軟件開發高手：十年磨一劍

要成為武林高手，需要長時間的勤學苦練。要成為軟件開發高手，又需要多長時間呢？《Modern C++ Design》的作者Andrei Alexandrescu認為：一個人有可能在２０幾歲就成為編程高手，但要成為設計高手卻需要熬到３５歲左右。以２３歲大學畢業計算，要經過漫長的１２年時間。

以我個人為例（我尚不敢自認是設計高手），２２歲大學畢業后，在某研究所用８０８６匯編語言寫一些小規模的程序，頗覺得心應手。凡是能用流傳圖表示的問題，都似乎不在話下。工作中，與同事共同切磋結構化程序設計，并能有意識地用于實踐中。

三年后，承接一個縱向課題：在Windows上開發一個交互式排版系統。用Windows SDK開發。興奮之余，自然想起用結構化方法進行設計：把整個系統當成一個黑盒子（black box），輸出當然是排版結果，不管是什么格式，輸入是···。我卡住了。難道用戶操作是輸入嗎？但用戶操作有那么多，怎么表示呢？系統的數據流圖該怎么畫？數據字典該怎么寫？和同事討論n次后，仍不得其解。懊喪之余，先模仿Quark Express搭個界面吧。然后研究排版算法。程序結構經過至少三次大規模修改，終于能排出一些版式，并在兩年后通過了鑒定（鑒定后當然是將其束之高閣）。我從中體會到結構化開發方法不適合開發交互式系統。在開發初期，你不太可能正確地畫出數據流圖，而結構化設計方法完全依賴數據流圖。數據流圖發生改變，整個程序結構就要隨之改變。

后來，加入一家合資公司，擔任開發組長，有五、六個組員。這時我已讀過了邵維忠等譯的《面向對象的分析》、楊芙清等編譯的《面向對象的設計》和《Code Complete》中譯本。對面向對象的程序設計雖有所了解但仍是一知半解。

首先，我們用MSVC 1.5開發一個圖形編輯軟件。我用紙畫了20幾張對象圖，與同事討論通過后，開始編程。有人負責數據模型，有人負責用戶界面，有人負責圖形顯示。幾個月后，老板已可向潛在用戶進行展示，反應良好。老板和開發人員都被一種興奮的心情籠罩著。我們不斷地加新功能，老板不時地到展覽會上做演示。功能加齊了，開始讓潛在用戶試用。老板和我們都松了一口氣：就剩下改錯了，咱們是兵來將擋、水來土屯，沒什么可怕的。錯誤報告來了。我們信心滿滿地開始查錯改錯。有些錯誤很快地被改掉了。但最后我們發現錯誤源源不斷。改了一個錯誤有可能引起別的錯誤。軟件永遠達不到能用的地步。最后，時機被錯過。該軟件不得不被砍掉。懊喪之余，我們做了反省。大家都認為應盡早改錯。同時模模糊糊地覺得數據模型和用戶界面的程序一定要嚴格分開，否則程序極難修改。

后來，我們又開發一個類似Adobe Acrobat Exchange的PDF文件瀏覽器兼編輯器（當時Acrobat Exchange還不能顯示中、日、韓文）。這時，老板帶來一些過期的《C/C++ Users’ Journal》《Dr.Dobbs’ Journal》雜志。從書評中，我被幾本書吸引住了。一本是James Rumbough等著的《Object-Oriented Modeling and Design》，一本是現在大名鼎鼎的《Design Patterns》，還有就是Scott Meyers著的《Effective C++》和《More Effective C++》。我勸說老板買了這幾本書，并攛掇他買了一個CASE（計算機輔助軟件工程）工具：Select OMT 仔細研讀這幾本書后，頗有頓開茅塞之感。最大的收獲在于了解到降低類之間耦合度的重要性。一個類的實現細節發生變化，不應該影響使用該類的其它類的內部實現。更妙的是有不少Design Pattern能馬上用到我們的軟件中。

我用Select OMT軟件畫了一些高層的類圖、狀態圖和數據流圖等，并讓同事們審查。同事們都覺得通過這些圖對軟件的總體設計有了更好的把握。在寫程序的過程中，我們不斷調整程序結構以盡可能減小類之間的耦合度。老板很早就安排了專職測試人員。發現問題，馬上修改。一年后，我們的軟件終于通過了用戶的試用，賣出去了。當時，我可說是信心滿滿。

此后，我做了一年半多媒體編程。發現還是對系統開發更感興趣。于是加入了Quark軟件公司，開發一個基于CORBA的文件管理系統。這是我第一次參與異地開發，也是第一次大規模使用STL。我驚嘆于STL設計之妙，同時也對自己的信心打了折扣。此后，我閱讀了Martin Fowler著的《UML Distilled》、Bertrand Meyer著的《Object Oriented Software Construction》等書籍。并開始使用Rational Rose。Quark公司的技術文檔管理、設計復查、代碼復查、質量管理以及德國人（Quark公司德國分公司）嚴謹的工作態度都給我留下了深刻印象。

項目組下分開發組和測試組。開發組中有一個４到５人組成的設計小組負責軟件總體設計，其中一個人負責技術文檔，確保文檔反映最新的設計。定期進行設計復查。復查時，項目組成員全部參加，并可提出問題或建議。得出結論后，馬上付諸實施。開發組下又設若干小組。小組內定期進行代碼復查。由組長選出每個組員的源文件，交其他組員復查，盡量挑出所有的毛病。如果代碼太次，要打回從新寫過。代碼復查既能保證軟件質量，又是大家學習的一個機會。

一年半后，我離開Quark，加盟Sybase，參與PowerBuilder的維護和新版本的開發。這是我第一次參與軟件維護，令我認識到軟件維護的重要性，認識到編寫可維護的代碼是軟件開發的一個重要課題。Sybase系統化的質量跟蹤系統和用戶支援系統讓我獲益匪淺。在此期間，我閱讀了《Large-scale Software Development in C++》、Martin Fowler著的《Refectoring》、Andrei Alexandrescu著的《Modern C++ Design》，Herb Sutter著的《Exceptional C++》和《More exceptional C++》，以及Kent Beck著的《Extreme Programming Explained》等書籍。對軟件開發與維護有了進一步了解，但同時也更認識到軟件開發之難。

回想十幾年蹣跚走過的路，好像也略有所悟。試總結出以供參考：

1）要熟練掌握至少一種編程語言。我覺得最好是C++。掌握了C++，學習其它語言如Java或C#等并非難事，因為各種面向對象的程序語言盡管在語法上可能有很大區別，在語義上卻大同小異。

2）不要寄希望于一次就把軟件設計好。在開發初期，要盡量用最簡單的設計實現最基本的功能，以使你的軟件盡早地能實際運行，不要過于拘泥于細節。這樣你才能盡早得到反饋，才能更直觀更全面地理解你所面對的問題。你所關注的重點應依次是Make it work, make it right, make it fast。

3）軟件結構要分塊分層。低層模塊不要依賴于上層模塊。一個類、一個接口或一個函數都應只做一件事。沒有本質聯系的類或接口就不應有耦合關系。舉例而言，要用MVC（Model View Controller）Design Pattern切斷用戶界面與數據模型之間的直接關聯。

4）軟件設計的主要工作是給類分配責任（responsibilities）。盡量不要把類設計成控制者（controller），而要設計成協調者（coordinator）。控制者凡事自己做，協調者讓別人做。控制者的邏輯往往很復雜，難于維護；協調者邏輯簡單，易于維護。要站在類的使用者角度設計類的外部行為。要講究一點軟件美學，即簡單、清晰、一致、平衡等。

5）了解并運用UML、Design Patterns、Unit Test、Design by Contract等。6）使用代碼管理系統和質量跟蹤系統。

7）了解各種軟件開發過程控制方法，并找出適合你的方法。8）閱讀經典書籍，研讀經典代碼，訂閱雜志，與同行切磋。

在這行越久越覺得軟件開發難。軟件開發歷史還很短，才50年，還不是一門系統化的學科。有些人甚至認為軟件設計與編程是一門藝術。但軟件藝術大師還太少，而且我們很難直接欣賞到他們的杰作，除非所有的設計文檔和代碼都公開。軟件更容易藏污納垢。一個用戶界面很漂亮的軟件，內部設計和代碼卻很可能臭不可聞。一個地板傾斜、墻壁裂縫、屋頂漏水的房子沒有人會買。一個設計很爛的軟件卻可能賣得不錯。但這樣的軟件能撐多久呢？ 軟件設計與編程已經很難，而這僅僅是軟件開發的一個方面，軟件開發過程控制也很難，也許更難。成為軟件開發高手要走一條漫長的路，何日才能仗劍走天涯？

第二篇：一個C++程序員的心得

六年前，我剛熱戀“面向對象”（Object-Oriented）時，一口氣記住了近十個定義。六年后，我從幾十萬行程序中滾爬出來準備寫點心得體會時，卻無法解釋什么是“面向對象”，就象說不清楚什么是數學那樣。軟件工程中的時髦術語“面向對象分析”和“面向對象設計”，通常是針對“需求分析”和“系統設計”環節的。“面向對象”有幾大學派，就象如來佛、上帝和真主用各自的方式定義了這個世界，并留下一堆經書來解釋這個世界。

有些學者建議這樣找“對象”：分析一個句子的語法，找出名詞和動詞，名詞就是對象，動詞則是對象的方法（即函數）。

當年國民黨的文人為了對抗毛澤東的《沁園春·雪》，特意請清朝遺老們寫了一些對仗工整的詩，請蔣介石過目。老蔣看了氣得大罵：“娘希匹，全都有一股棺材里腐尸的氣味。”我看了幾千頁的軟件工程資料，終于發現自己有些“弱智”，無法理解“面向對象”的理論，同時醒悟到“編程是硬道理。”

面向對象程序設計語言很多，如Smalltalk、Ada、Eiffel、Object Pascal、Visual Basic、C++等等。C++語言最討人喜歡，因為它兼容C 語言，并且具備C 語言的性能。近幾年，一種叫Java 的純面向對象語言紅極一時，不少人叫喊著要用Java 革C++的命。我認為Java 好比是C++的外甥，雖然不是直接遺傳的，但也幾分象樣。外甥在舅舅身上玩耍時灑了一泡尿，倆人不該為此而爭吵。

關于C++程序設計的書藉非常多，本章不講C++的語法，只講一些小小的編程道理。如果我能早幾年明白這些小道理，就可以大大改善數十萬行程序的質量了。

1.C++面向對象程序設計的重要概念

早期革命影片里有這樣一個角色，他說：“我是黨代表，我代表黨，我就是黨。”后來他給同志們帶來了災難。

會用C++的程序員一定懂得面向對象程序設計嗎？

不會用C++的程序員一定不懂得面向對象程序設計嗎？

兩者都未必。就象壞蛋入黨后未必能成為好人，好人不入黨未必變成壞蛋那樣。

我不怕觸犯眾怒地說句大話：“C++沒有高手，C 語言才有高手。”在用C 和C++編程8年之后，我深深地遺憾自己不是C 語言的高手，更遺憾沒有人點撥我如何進行面向對象程序設計。我和很多C++程序員一樣，在享用到C++語法的好處時便以為自己已經明白了面向對象程序設計。就象擠掉牙膏賣牙膏皮那樣，真是暴殄天物呀。

人們不懂拼音也會講普通話，如果懂得拼音則會把普通話講得更好。不懂面向對象程序設計也可以用C++編程，如果懂得面向對象程序設計則會把C++程序編得更好。本節講述三個非常基礎的概念：“類與對象”、“繼承與組合”、“虛函數與多態”。理解這些概念，有助于提高程序的質量，特別是提高“可復用性”與“可擴充性”。1.1 類與對象

對象（Object）是類（Class）的一個實例（Instance）。如果將對象比作房子，那么類就是房子的設計圖紙。所以面向對象程序設計的重點是類的設計，而不是對象的設計。類可以將數據和函數封裝在一起，其中函數表示了類的行為（或稱服務）。類提供關鍵字public、protected 和private 用于聲明哪些數據和函數是公有的、受保護的或者是私有的。

這樣可以達到信息隱藏的目的，即讓類僅僅公開必須要讓外界知道的內容，而隱藏其它一切內容。我們不可以濫用類的封裝功能，不要把它當成火鍋，什么東西都往里扔。

類的設計是以數據為中心，還是以行為為中心？

主張“以數據為中心”的那一派人關注類的內部數據結構，他們習慣上將private 類型的數據寫在前面，而將public 類型的函數寫在后面，如表8.1(a)所示。

主張“以行為為中心”的那一派人關注類應該提供什么樣的服務和接口，他們習慣上將public 類型的函數寫在前面，而將private 類型的數據寫在后面，如表8.1(b)所示。

很多C++教課書主張在設計類時“以數據為中心”。我堅持并且建議讀者在設計類時“以行為為中心”，即首先考慮類應該提供什么樣的函數。Microsoft 公司的COM 規范的核心是接口設計，COM 的接口就相當于類的公有函數[Rogerson 1999]。在程序設計方面，咱們不要懷疑Microsoft 公司的風格。

設計孤立的類是比較容易的，難的是正確設計基類及其派生類。因為有些程序員搞不清楚“繼承”（Inheritance）、“組合”（Composition）、“多態”（Polymorphism）這些概念。2回頂部 1.2 繼承與組合

如果A 是基類，B 是A 的派生類，那么B 將繼承A 的數據和函數。示例程序如下： class A { public: void Func1(void);void Func2(void);};class B : public A { public: void Func3(void);void Func4(void);};// Example main(){ B b;// B的一個對象

b.Func1();// B 從A 繼承了函數Func1 b.Func2();// B 從A 繼承了函數Func2 b.Func3();b.Func4();}

這個簡單的示例程序說明了一個事實：C++的“繼承”特性可以提高程序的可復用性。正因為“繼承”太有用、太容易用，才要防止亂用“繼承”。我們要給“繼承”立一些使用規則：

一、如果類A 和類B 毫不相關，不可以為了使B 的功能更多些而讓B 繼承A 的功能。

不要覺得“不吃白不吃”，讓一個好端端的健壯青年無緣無故地吃人參補身體。

二、如果類B 有必要使用A 的功能，則要分兩種情況考慮：

（1）若在邏輯上B 是A 的“一種”（a kind of），則允許B 繼承A 的功能。如男人（Man）是人（Human）的一種，男孩（Boy）是男人的一種。那么類Man 可以從類Human 派生，類Boy 可以從類Man 派生。示例程序如下： class Human { ? };class Man : public Human { ? };class Boy : public Man { ? };

（2）若在邏輯上A 是B 的“一部分”（a part of），則不允許B 繼承A 的功能，而是要用A和其它東西組合出B。例如眼（Eye）、鼻（Nose）、口（Mouth）、耳（Ear）是頭（Head）的一部分，所以類Head 應該由類Eye、Nose、Mouth、Ear 組合而成，不是派生而成。示例程序如下： class Eye { public: void Look(void);};class Nose { public: void Smell(void);};class Mouth { public: void Eat(void);};class Ear { public: void Listen(void);};// 正確的設計，冗長的程序 class Head { public: void Look(void){ m_eye.Look();} void Smell(void){ m_nose.Smell();} void Eat(void){ m_mouth.Eat();} void Listen(void){ m_ear.Listen();} private: Eye m_eye;Nose m_nose;Mouth m_mouth;Ear m_ear;};

如果允許Head 從Eye、Nose、Mouth、Ear 派生而成，那么Head 將自動具有Look、Smell、Eat、Listen 這些功能： // 錯誤的設計

class Head : public Eye, public Nose, public Mouth, public Ear { };

上述程序十分簡短并且運行正確，但是這種設計卻是錯誤的。很多程序員經不起“繼承”的誘惑而犯下設計錯誤。

一只公雞使勁地追打一只剛下了蛋的母雞，你知道為什么嗎？

因為母雞下了鴨蛋。

本書3.3 節講過“運行正確”的程序不見得就是高質量的程序，此處就是一個例證。3回頂部 1.3 虛函數與多態

除了繼承外，C++的另一個優良特性是支持多態，即允許將派生類的對象當作基類的對象使用。如果A 是基類，B 和C 是A 的派生類，多態函數Test 的參數是A 的 指針。那么Test 函數可以引用A、B、C 的對象。示例程序如下： class A { public: void Func1(void);};void Test(A *a){ a->Func1();} class B : public A { ? };class C : public A { ? };// Example main(){ A a;B b;C c;Test(&a);Test(&b);Test(&c);};

以上程序看不出“多態”有什么價值，加上虛函數和抽象基類后，“多態”的威力就顯示出來了。

C++用關鍵字virtual 來聲明一個函數為虛函數，派生類的虛函數將（override）基類對應的虛函數的功能。示例程序如下： class A { public: virtual void Func1(void){ cout<< “This is A::Func1 n”} };void Test(A *a){ a->Func1();} class B : public A { public: virtual void Func1(void){ cout<< “This is B::Func1 n”} };class C : public A { public: virtual void Func1(void){ cout<< “This is C::Func1 n”} };// Example main(){ A a;B b;C c;Test(&a);// 輸出This is A::Func1 Test(&b);// 輸出This is B::Func1 Test(&c);// 輸出This is C::Func1 };

如果基類A 定義如下： class A { public: virtual void Func1(void)=0;};

那么函數Func1 叫作純虛函數，含有純虛函數的類叫作抽象基類。抽象基類只管定義純虛函數的形式，具體的功能由派生類實現。

結合“抽象基類”和“多態”有如下突出優點：

（1）應用程序不必為每一個派生類編寫功能調用，只需要對抽象基類進行處理即可。這一招叫“以不變應萬變”，可以大大提高程序的可復用性（這是接口設計的復用，而不是代碼實現的復用）。

（2）派生類的功能可以被基類指針引用，這叫向后兼容，可以提高程序的可擴充性和可維護性。以前寫的程序可以被將來寫的程序調用不足為奇，但是將來寫的程序可以被以前寫的程序調用那可了不起。4回頂部 良好的編程風格

內功深厚的武林高手出招往往平淡無奇。同理，編程高手也不會用奇門怪招寫程序。良好的編程風格是產生高質量程序的前提。2.1 命名約定

有不少人編程時用拼音給函數或變量命名，這樣做并不能說明你很愛國，卻會讓用此程序的人迷糊（很多南方人不懂拼音，我就不懂）。程序中的英文一般不會太復雜，用詞要力求準確。匈牙利命名法是Microsoft 公司倡導的[Maguire 1993]，雖然很煩瑣，但用習慣了也就成了自然。沒有人強迫你采用何種命名法，但有一點應該做到：自己的程序命名必須一致。

以下是我編程時采用的命名約定：

（1）宏定義用大寫字母加下劃線表示，如MAX_LENGTH；

（2）函數用大寫字母開頭的單詞組合而成，如SetName, GetName ；

（3）指針變量加前綴p，如*pNode ；

（4）BOOL 變量加前綴b，如bFlag ；

（5）int 變量加前綴i，如iWidth ；

（6）float 變量加前綴f，如fWidth ；

（7）double 變量加前綴d，如dWidth ；

（8）字符串變量加前綴str，如strName ；

（9）枚舉變量加前綴e，如eDrawMode ；

（10）類的成員變量加前綴m_，如m_strName, m_iWidth ；

對于int, float, double 型的變量，如果變量名的含義十分明顯，則不加前綴，避免煩瑣。如用于循環的int 型變量i,j,k ；float 型的三維坐標（x,y,z）等。2.2 使用斷言

程序一般分為Debug 版本和Release 版本，Debug 版本用于內部調試，Release 版本發行給用戶使用。斷言assert 是僅在Debug 版本起作用的宏，它用于檢查“不應該”發生的情況。以下是一個內存復制程序，在運行過程中，如果assert 的參數為假，那么程序就會中止（一般地還會出現提示對話，說明在什么地方引發了assert）。//復制不重疊的內存塊

void memcpy(void *pvTo, void *pvFrom, size_t size){ void *pbTo =(byte *)pvTo;void *pbFrom =(byte *)pvFrom;assert(pvTo!= NULL && pvFrom!= NULL);while(size--> 0)*pbTo + + = *pbFrom + +;return(pvTo);}

assert 不是一個倉促拼湊起來的宏，為了不在程序的Debug 版本和Release 版本引起差別，assert 不應該產生任何副作用。所以assert 不是函數，而是宏。程序員可以把assert 看成一個在任何系統狀態下都可以安全使用的無害測試手段。

很少有比跟蹤到程序的斷言，卻不知道該斷言的作用更讓人沮喪的事了。你化了很多時間，不是為了排除錯誤，而只是為了弄清楚這個錯誤到底是什么。有的時候，程序員偶爾還會設計出有錯誤的斷言。所以如果搞不清楚斷言檢查的是什么，就很難判斷錯誤是出現在程序中，還是出現在斷言中。幸運的是這個問題很好解決，只要加上清晰的注釋即可。這本是顯而易見的事情，可是很少有程序員這樣做。這好比一個人在森林里，看到樹上釘著一塊“危險”的大牌子。但危險到底是什么？樹要倒？有廢井？有野獸？除非告訴人們“危險”是什么，否則這個警告牌難以起到積極有效的作用。難以理解的斷言常常被程序員忽略，甚至被刪除。[Maguire 1993]

以下是使用斷言的幾個原則：

（1）使用斷言捕捉不應該發生的非法情況。不要混淆非法情況與錯誤情況之間的區別，后者是必然存在的并且是一定要作出處理的。

（2）使用斷言對函數的參數進行確認。

（3）在編寫函數時，要進行反復的考查，并且自問：“我打算做哪些假定？”一旦確定了的

假定，就要使用斷言對假定進行檢查。

（4）一般教科書都鼓勵程序員們進行防錯性的程序設計，但要記住這種編程風格會隱瞞錯誤。當進行防錯性編程時，如果“不可能發生”的事情的確發生了，則要使用斷言進行報警。5回頂部

2.3 new、delete 與指針

在C++中，操作符new 用于申請內存，操作符delete 用于釋放內存。在C 語言中，函數malloc 用于申請內存，函數free 用于釋放內 存。由于C++兼容C 語言，所以new、delete、malloc、free 都有可能一起使用。new 能比malloc 干更多的事，它可以申請對象的內存，而malloc 不能。C++和C 語言中的指針威猛無比，用錯了會帶來災難。對于一個指針p，如果是用new申請的內存，則必須用delete 而不能用free 來釋放。如果是用malloc 申請的內存，則必須用free 而不能用delete 來釋放。在用delete 或用free 釋放p 所指的內存后，應該馬上顯式地將p 置為NULL，以防下次使用p 時發生錯誤。示例程序如下： void Test(void){ float *p;p = new float[100];if(p==NULL)return;?// do something delete p;p=NULL;// 良好的編程風格 // 可以繼續使用p p = new float[500];if(p==NULL)return;?// do something else delete p;p=NULL;}

我們還要預防“野指針”，“野指針”是指向“垃圾”內存的指針，主要成因有兩種：

（1）指針沒有初始化。

（2）指針指向已經釋放的內存，這種情況最讓人防不勝防，示例程序如下： class A { public: void Func(void){?} };void Test(void){ A *p;{ A a;p = &a;// 注意a 的生命期 } p->Func();// p 是“野指針”，程序出錯 } 2.4 使用const

在定義一個常量時，const 比#define 更加靈活。用const 定義的常量含有數據類型，該常量可以參與邏輯運算。例如： const int LENGTH = 100;// LENGTH 是int 類型 const float MAX=100;// MAX 是float 類型 #define LENGTH 100 // LENGTH 無類型 #define MAX 100 // MAX 無類型

除了能定義常量外，const 還有兩個“保護”功能：

一、強制保護函數的參數值不發生變化

以下程序中，函數f 不會改變輸入參數name 的值，但是函數g 和h 都有可能改變name的值。void f(String s);// pass by value void g(String &s);// pass by referance void h(String *s);// pass by pointer main(){ String name=“Dog”;f(name);// name 的值不會改變 g(name);// name 的值可能改變 h(name);// name 的值可能改變 }

對于一個函數而言，如果其‘&’或‘*’類型的參數只作輸入用，不作輸出用，那么應當在該參數前加上const，以確保函數的代碼不會改變該參數的值（如果改變了該參數的值，編譯器會出現錯誤警告）。因此上述程序中的函數g 和h 應該定義成： void g(const String &s);void h(const String *s);

二、強制保護類的成員函數不改變任何數據成員的值

以下程序中，類stack 的成員函數Count 僅用于計數，為了確保Count 不改變類中的任何數據成員的值，應將函數Count 定義成const 類型。class Stack { public: void push(int elem);void pop(void);int Count(void)const;// const 類型的函數 private: int num;int data[100];};int Stack::Count(void)const { ++ num;// 編譯錯誤，num 值發生變化 pop();// 編譯錯誤，pop 將改變成員變量的值 return num;} 6回頂部 2.5 其它建議

（1）不要編寫一條過分復雜的語句，緊湊的C++/C 代碼并不見到能得到高效率的機器代碼，卻會降低程序的可理解性，程序出錯誤的幾率也會提高。

（2）不要編寫集多種功能于一身的函數，在函數的返回值中，不要將正常值和錯誤標志混在一起。

（3）不要將BOOL 值TRUE 和FALSE 對應于1 和0 進行編程。大多數編程語言將FALSE定義為0，任何非0 值都是TRUE。Visual C++將TRUE 定義為1，而Visual Basic 則將TRUE定義為-1。示例程序如下： BOOL flag;?

if(flag){ // do something } // 正確的用法 if(flag==TRUE){ // do something } // 危險的用法 if(flag==1){ // do something } // 危險的用法 if(!flag){ // do something } // 正確的用法

if(flag==FALSE){ // do something } // 不合理的用法 if(flag==0){ // do something } // 不合理的用法

（4）小心不要將“= =”寫成“=”，編譯器不會自動發現這種錯誤。

（5）不要將123 寫成0123，后者是八進制的數值。

（6）將自己經常犯的編程錯誤記錄下來，制成表格貼在計算機旁邊。小結

C++/C 程序設計如同少林寺的武功一樣博大精深，我練了8 年，大概只學到二三成。所以無論什么時候，都不要覺得自己的編程水平天下第一，看到別人好的技術和風格，要虛心學習。本章的內容少得可憐，就象口渴時只給你一顆楊梅吃，你一定不過癮。我借花獻佛，推薦一本好書：Marshall P.Cline 著的《C++ FAQs》[Cline 1995]。你看了后一定會贊不絕口。會編寫C++/C 程序，不要因此得意洋洋，這只是程序員基本的技能要求而已。如果把系統分析和系統設計比作“戰略決策”，那么編程充其量只是“戰術”。如果指揮官是個大笨蛋，士兵再勇敢也會吃敗仗。所以我們程序員不要只把眼光盯在程序上，要讓自己博學多才。我們應該向北京胡同里的小孩們學習，他們小小年紀就能指點江山，評論世界大事。

第三篇：C++程序員求職信

C++程序員求職信

光陰如水，找工作的黃金時間馬上就要到來，是時候好好地琢磨一下寫求職信的事情了哦。相信寫求職信是一個讓許多人都頭痛的問題，以下是小編幫大家整理的C++程序員求職信，僅供參考，歡迎大家閱讀。

尊敬的公司領導：

您好!

非常感謝您在百忙之中抽出寶貴的時間來垂覽我的求職材料!

我叫xx，是南開大學計算機系的一名本科大學生，即將面臨畢業。懷著對貴公司強烈的渴望和滿懷的激情，我十分希望成為貴公司的一份子!懇請貴公司給我這個機會!我也會向貴公司證明我的能力!

4年多以來，在老師的教育及個人的努力下，我具備了扎實的專業基礎知識，系統地掌握了c++語言、匯編語言、單片機原理、電子電路、計算機組成原理、數據結構、數據庫等有關理論，以及嵌入式系統開發的一些理論，同時也擁有一定的分析和設計能力。通過在校期間的試驗實習和課程設計的訓練我具備了較強的動手能力。

除了對計算機熱愛，在大學四年里我還不斷的學習英語知識，我深切的`感受到當今社會以及計算機行業，沒有過硬的英語能力是不行的，并且將會成為我們事業前進的瓶頸。我在大二上學期就通過了全國大學生英語四級考試。此外，我還積極參加校內的各種活動以及校外的各種社會活動，抓住每一個機會，鍛煉自己的能力。

我通過各種渠道大致了解了貴公司的情況，知道貴公司是個很有發展前途的具有現代潮流的公司，具有很大的活力，而我也非常希望能加入這樣的企業，盡自己最大努力為公司的發展奉獻自己的微薄之力。

我十分熱愛貴單位所從事的事業，殷切地期望能夠在您的領導下，為貴公司添磚加瓦;同時也在您的領導下發揮出我的實力與才能，在實踐中不斷學習、進步，在能力和素質方面進一步完善自我，為貴公司做出更大的貢獻。無論您是否選擇我，我都祝愿貴公司的事業蒸蒸日上!

此致

敬禮！

第四篇：C++程序員簡歷（寫寫幫推薦）

個人簡歷

個人概況

姓 名：羅楊 性 別：男

籍 貫：四川.巴中 出生年月：1994-10 學 歷：專科 畢業學校：四川聯合經濟專修學院

專 業：軟件技術 聯系電話：*** 電子郵箱：berserkerluoyang@163.com 求職意向

C/C++開發相關工作

專業技能

能夠熟練使用Microsoft office辦公軟件。

熟悉8086匯編基礎。

良好的C/C++編程基礎，熟悉Linux系統上開發環境及工具gcc/g++等。

掌握Unix/Linux內存管理，文件與目錄管理，IO，進程間通信，多線程同步機制。

熟悉Unix/Linux操作系統，熟悉Vi使用。

熟悉Qt(圖形界面)編程開發。

熟悉Socket網絡編程。

熟悉SQL語句,了解數據庫的Pro*C/C++Oracle數據庫連接技術。

工作及培訓經歷

2012.5 — 2012.8 大千勞務 普工 工作描述： 負責施放施工線。

工作收獲： 通過這份工作，我鍛煉了自己的吃苦能力，意志力及解決問題能力。在語言表達能力得

到了提高，培養了踏實穩重的做事心態。

2014.4 — 2014.8 達內科技C++培訓

培訓課程： linux基礎，標準C編程，標準C++編程，數據結構與算法，STL/模板，UC高級編程，QT編程，Oracle，Windows內核編程，MFC等

培訓收獲： 編程技能，邏輯思維能力得到突破性提高。

項目經驗

項目名稱一 : ATM系統 開發周期 ： 7天

開發工具 ： C、Vi、GCC平臺/語言 ： Linux 項目功能描述： 使用socket網絡編程模擬服務端（Server）客戶端（Client）功能，服務端采用

和您一起，共創輝煌

線程處理每個客戶端的各種請求，服務端與客戶端使用TCP協議通信，模擬實現客戶的登錄、開戶、存款、取款、轉賬、查賬、銷戶及更改密碼的功能。

項目收獲 ： 初步了解了軟件開發流程，socket的通信原理，和基本框架，完成了部分功能的實現，進行了bug的調試、深入理解了進程通信的原理。進一步提高了自己的動手能力。

項目名稱二 ： 網絡聊天室 開發周期 ： 3天

開發工具 ： Vi、C、gcc 開發平臺 ： Linux 項目負責 ： 獨立完成項目服務端和客戶端的實現

項目功能 : 使用socket網絡編程，實現聊天室的服務端和客戶端、實現多人聊天，由客戶發消

息給服務端，服務端采用多線程處理每個客戶端的消息并轉發

項目收獲 ： 動手能力和邏輯思考能力得到了提高,進一步了解了socket的通信原理。

項目名稱三 ： 俄羅斯方塊 開發工具 ： C++、Qt 開發平臺 ： Linux 項目負責 ： 獨立完成程序的開發。

項目功能 ： 使用鍵盤事件完成游戲過程，實現菜單功能，實現模塊化編程。

項目收獲 ： 動手能力，及邏輯思維能力得到提高，進一步理解C++面向對象編程思想

項目名稱四 ： 數據挖掘系統（DMS）

開發工具 ： C++、Oracle、Vim、Qt、gcc 開發平臺 ： Linux 項目負責 ： 完成系統的數據采集端、實現數據讀取、數據匹配、數據發送、數據接收、數據存

儲和數據整合功能

項目功能 ： 系統基于DMS電信服務需求，采用C/S架構，服務器端采用Socket通信和Unix多

線程設計，完成并實現以Unix作為后臺服務器的電信服務管理系統。系統采集用戶

使用服務(移動電話/固話/服務器出租/WEB服務器/電子 郵件服務器等)的數據，并

作為收費憑據。系統擁有數據采集，計費管理，數據整合三個子系統，采集系統分

為采集客戶端和采集服務端。

項目收獲 ： 熟悉了oracle數據庫的應用，對C++面向對象有了更深入的了解。進一步掌握了 socket網絡編程，對模塊化設計有了深入理解。

個人評價

本人對編程游濃厚的興趣，有效代碼量超過5萬行，熱愛計算機行業。平時很活潑能與他人和平相處。有很好的問題分析能力，對解決具有挑戰性問題充滿激情。較強的自學和協作能力，踏實認真。有較強的邏輯思維能力。

和您一起，共創輝煌

第五篇：C語言C++程序員編程必備

Java，NET，PHP，Ruby，Perl 和 Python 等，但今天我們要討論的是兩個最古老和流行的語言的C和C++。它們都有其特殊的地方，更有效的功能和支持的工具，這兩種語言仍然很活躍。

今天我們整理了一些令人印象深刻的IDE（集成開發環境）和編譯器推薦給 C 和 C++ 程序員。集成開發環境，主要用于提供軟件應用的各種組件而開發的，其中最流行的功能是它們都有吸引力的用戶界面。1)Best IDE for C/C++ – kDevelop KDevelop 是基于 KDevPlatform 的可使用開源插件擴展的 IDE。KDevPlatform 是一種可以用來作為 IDE 的基礎庫的開源集。

2)Best IDE for C/C++-Anjuta Anjuta Devstudio 具有先進的編程工具，包括項目管理，應用程序向導，交互式調試器，源代碼編輯器，版本控制，GUI設計器，分析器和許多工具，另一個偉大的開發工作室。此工具提供的 C/C++ 程序員有很大強大的用戶界面開發接口。

3)Best IDE for C/C++Eclipse CDT Eclipse CD 是最強大和最流行的IDE之一，提供了更高效的功能，如：項目的創建和管理，構建支持不同的工具鏈，標準make編譯，源代碼導航，各種來源的知識工具，代碼編輯器，語法高亮，折疊和超鏈接導航，源代碼重構和代碼生成，可視化調試工具，包括內存，寄存器等等。

7)Best IDE for C/C++ – Compilr Compilr 是在線集成開發工具，讓您與令人印象深刻的功能和簡單的用戶界面編寫代碼。該工具支持的編程語言中廣泛的C，C + + JAVA，HTML等等。

8)Best IDE for C/C++Netbeans C++ Netbeans 的工具包括許多適合 C 和 C++ 項目類型模板，可以 使用動態庫和靜態創建 C/C++ 應用程序庫。它擁有迷人的功能:代碼協助，編譯器配置，單元測試，源檢查，遠程開發和文件導航等等。

10)Best IDE/Compiler for C/C++Ultimate++ Ultimate++是對于 C++ 程序員來說是很好框架。這個 IDE 引入了模塊化概念，可以結合 GCC，MinGW 和 Visual C++。

12)Best Compiler for C/C++-Digital Mars DigitalMars 是一款高性能的 C/C++ 編譯器。包括的功能，如速度最快的編譯/鏈接時，強

HTML文檔，反匯編，圖書管理員，資源編譯器，make等，命令行和GUI版本，教程，代碼示例，在線更新，標準模板庫等等。

13)Best IDE for C-C-Free

14)Best Compiler for C/C++ – MinGW MinGW 編譯器提供訪問微軟的C運行庫和一些特定語言運行庫的功能。

15)Best Compiler for C – Tiny C Compiler iny C Compiler 是最好的編譯器之一，讓開發人員可以在任何地方編譯代碼，可以使用任何 C 動態庫，編譯并直接執行C++源程序，也包含完整的 C 預處理器和 GNU 匯編器。

@扣丁學堂 智悅分享