程式員學習

來自http://blog.pfan.cn/vc2006/17982.html

源代碼的學習

1. 畫出整個程式的流程圖，了解整個程式流程的思想。畫流程圖的方式更讓人很直接 的了解程式的整體流程，而不會被代碼所幹擾，讓程式員總體上把握整個程式。

2. 對流程各節點(函數或過程)的了解。流程的每一節點是構成整個流程的不可缺少的部份。

3. 再把流程和流程各節點串起來了解整個程式，可能的話最好寫出讀書筆記。

4. 如果想深刻的學習到源代碼的精髓所在，請寫一個相近的程式進行操練。當你了解了這個程式并不表明你掌握了這個程式，隻有在你操練一個相近的程式時，你才知道你到底了解了多少，掌握了多少。

其實源代碼的學習這是一個從整體到不斷細化的過程，是一個極為繁瑣的過程同時也是一個不斷認清事物本原的過程。

很多程式員(包括我自己)在相當長的時間内,過份注重程式代碼的細節部份，而忽略了程式的有機整體，這不能不說是一種悲哀。

特别是軟體大工業時代的現在，由于項目的龐大，整個項目被人為的分割成七零八落的幾個獨立小塊 (這就更須要有人對整個項目的統領),程式員在這幾個小塊中各自為戰，堕落自己的思維，限制在狹小的空間中還自得其樂。整個一井底之蛙。

但是我們也要看到，現在有越來越多的程式員潛意識裡明白了這個缺陷，正在不斷的改進。

其實我真正想說的是，大凡世事紛繁複雜，但道理卻殊途同歸，這才是萬法歸一的了解。

By [zbkid] at 22:41:36 | Comments[0] | 31 views

 軟體開發入門學習的個人看法  [2005-1-21]

沙鷗 ([email protected])

踏實

偶然在網上看到《由C#風潮想起的－給初學程式設計者的忠告》一文. 其中一個角度：避免“浮躁”，倡導“踏實”的學習方法，我是很認同的，但總覺該文作者标題“-給初學程式設計者的忠告”太大，是以在其文列出的一些具體的“操作方法”上我認為可以探讨，如同自己在某次公司總結會上就《軟體開發，我們積累的是什麼？》為題跟同僚聊了半個多小時後，其中一個同僚提到希望我能繼續把這個題目細化，就剛入行的他們具體該如何發展有更“具操作性”的指引，當時我是跟他們說這隻是我在這一行呆了5年多的體會，談“指引”還太遠，隻是可以提出來大家思考、讨論。

不要過度貶低編碼

不要真的認為"不少大師級的計算機技術研究者是不懂程式設計的",做軟體開發編碼是最最基礎的東西,隻有踏踏實實的掌握好這個基礎你才有辦法往上走,不管做分析做設計做項目管理你都需要能清楚東西是如何實作的?可不可以實作?否則肯定出現大量的:"設計是設計,編碼是編碼","産品都是代碼人員從頭到尾實作的","究竟需花多少時間,難度有多大,開發人員說了算","品質/成本/進度全是黑匣子"...現象,如果你是做編碼那編碼就更重要了.是以對于有志從事這個行業(軟體開發)的個人來說,必須先從"重視編碼"開始.過了這一關才能去考慮做系統分析,做項目管理...

軟體開發的各個環節是相輔相承的,分析有分析的重要,設計有設計的重要,編碼有編碼的重要,測試實施也各有其地位,任何一個環節搞不好就如同我們熟悉的木桶理論,"最薄弱的一個環節制約着其總容量".

既然編碼重要,那該如何學編碼?

專心學好一門語言

算算自己用過的語言也不少（括弧裡為使用該語言寫的比較有代表性的東東）,C（dos版的圖像/圖示編輯工具,96年的《電腦報》有介紹）,C++（可自定義方塊形狀的方塊遊戲,被收錄于99年《軟體》雜志的附送CD光牒上）,彙編(DOS漢字系統,97年底完成),PB(學校自動排課/排考子產品,98年),ASP(一套web版的企業資訊系統,99年),VB(企業資訊系統的核心元件,99年),delphi(工作流平台,元件式GIS系統等),Java（Delphi Client + J2EE Server協同實作）,.Net（規則引擎）,PHH...

看起來好象也不少,回過頭來想想自己真正認真學過的語言隻有一個,就是“C”, Dos年代的TC2.0,用它寫了大量的小程式,比較系統的了解了程式設計是怎麼一回事,記得那個時候看到什麼軟體都要琢磨它是如何實作的?如果讓我來實作該如何做?也模仿了不少東西,雖然多是很表面的模仿但對自己程式設計思維的鍛煉很有好處.後來用其它語言基本上都隻是翻翻幫助,然後找找其Demo代碼來看看,很快就可進入狀态.

語言都是差不多的,重要的是“編碼的思想”,具備了該思想語言就隻是工具了,用什麼工具實作都差不多,該思想的形成是需要“磨練”的,就是“專心使用一門語言”來磨練(甚至需要有“咬文嚼字的孔已己作風”),然後可“一理通百理通”,不然你隻是浮于表面的去學再多的語言都沒有.都不能拿來做真正的開發.都不能了解“編碼”的内涵.

如在今年招聘面試的時候看到太多寫着什麼語言都精通(或熟練)的畢業生,我慣用的方法是給他(她)一張紙一支筆,讓他(她)用自己最了解的語言寫一個算階乘的函數,這個問題你一看肯定說很簡單,好,接着我會往下問,可以有多少種方法來實作:循環,遞歸…還有嗎?你能寫出多少種來?(代碼基本結構模式的考察).代碼品質如何? 有沒有考慮錯誤處理(太多人寫的代碼會進入死循環比如輸入的是負數) ? int的上限是多少,用long? 如果輸入值比較大,算得出結果嗎,該如何去實作可以計算很大數的該函數?...看着他(她)寫出來的代碼一個個問題的問就得了,不管你用什麼語言,不管你“精通”多少種語言,我隻問這些用什麼語言來解決問題都需要的基礎的東西, 就是“編碼的思想”.

在學專一門語言的基礎上新東西當然要跟,不然在這個行業你是很難“混下去”的,但有這“學專一門”的前提後,你跟起來就輕松了,而不用總是得“追”~

在“專”一門語言的過程中為解決問題你會發現“算法”很重要,這就是接下來要說的“基礎”了.

基礎很重要

面試的時候我一般都會問,基礎知識學得如何? 一般重點問的是:《資料結構》, 《編譯原理》, 《資料庫原理》的内容.至于《由》文提到的:《彙編語言》,《 Windows 程式設計》我是不會問的.這些是可以進一步學習的東西,但對現在的開發來說不是必須的.《軟體工程》我向來不問,教材理論跟實際差得太遠了~

《資料結構》很重要,不懂資料結構很多編碼就是“蠻幹”,而且往往把“簡單問題複雜化”,甚至複雜到不可能解決.認真學習《資料結構》并多做嘗試用你熟悉的語言去實作裡面的算法,你會發覺“世界真奇妙”~不要認為你不會去開發“程式設計語言”不需要學習《編譯原理》, 《編譯原理》裡面包含了太多開發軟體的“奇妙”的思想案例,認真體會你肯定會被其解決問題的方法折服,從中你能體會到很多東西,對以後做軟體(不管是設計還是編碼等)大有幫助,裡面有很多現存的方法可用在你的項目中,而這些跟《資料結構》是互為補充的.在這些基礎上接下來《設計模式》一書你也一定得看看.

很多應用都離不開資料庫,最終總得找個地方來“操縱,存儲,分析資料”,關于範式,關于鎖,關于SQL,關于笛卡兒那一套你總得了解了解,不然無法入手,這就需要好好學習《資料庫原理》了.單純知道幾條SQL語句是遠遠不夠的,如何保證資料的完整性,安全性?如何提高效率等等都需要這些基礎的支援~

當然英文也是基礎,看英文資料确實重要，不單是書,還有網絡上的大量資料,論壇…看的時候别害怕就是了，畢竟都是受過高等教育的，英語也學了那麼多年起碼都有點底吧，配合這兩個工具：《金山詞霸》及Google.com，不懂的單詞“即指即譯”，但很多名詞或基礎知識不是靠單詞解釋能清楚的，配合搜尋引擎查查相關資料看看，記住一點，看到不懂的東西多看幾遍，默記一小會，日積月累你能看懂的東西就多了。

興趣

最後該說說的就是興趣問題,如果你能對它真正感興趣(如果要從事軟體開發又沒興趣的話趕緊先培養興趣去^_^),對看技術資料就想别人看武俠小說看球賽一樣的話,再配合上面提到的幾點(踏實, 先專後廣, 基礎紮實)相信在這一行多少是可以做點東西出來的~~

By [zbkid] at 8:20:45 | Comments[0] | 38 views

 成為軟體高手的幾個忌諱  [2005-1-20]

主 題: 成為軟體高手的幾個忌諱

作 者: 阿榮 (進士)

所屬論壇: 灌水樂園

本帖分數: 0

回複次數: 34

發表時間: 2004-7-19 21:13:18

正文内容:

1） 不會英語：CS源于美國，重量級的文檔都是英文的。不會英語，那麼你隻能忍受拙劣的翻譯和大延遲的文檔（翻譯出來的文檔幾乎都是很久以前出版的東西）。

2） 急于求成：什麼都沒學習就開始程式設計是最大的忌諱。寫C++程式文法都能錯，資料結構連線性表都不知道，資料庫不知道關系模型，TCP程式設計不知道socket，還是先坐下來學習幾年再說（如果說工作急需，我隻能說：早幹嘛去了）

3） 過于好問：勤學好問是一種很好的品質，但是如果把勤學丢了，隻留下好問，就是一個惡劣的素質了。事無巨細都去請教别人，一則會讓人厭煩，二則由于沒有系統學習過程，也是不可能學習好的。

4） 隻會豔羨别人和說别人不該拿那麼多錢，而自己卻收入微薄：老實說，絕大多數情況下，收入的高低和你的水準是有正相關系的。不是否認有關系的存在，但是絕對不會10個人中9個人有關系而獨獨你沒有。少抱怨一些多學習一些，提升自己才是最重要的。

5） 過于不求甚解和過于求甚解。了解為什麼是很重要的，但是要學習的東西很多，如果什麼都弄明白，那麼估計頭發白了還沒有找到所有答案。當然如果什麼都不想細緻了解，那麼隻能去做藍領了。

6） 過分崇拜他人：我想信很多人都是很厲害的，值得大家崇拜，但是如果過于崇拜，把他們的話當成聖經就沒有必要了。你需要突破他們，而不是崇拜他們。

7） 不想吃苦：IT業高收入和高競争是聯系在一起的。沒有付出永遠别想進步。

By [zbkid] at 11:32:51 | Comments[0] | 36 views

 論程式設計方法  [2005-1-19]

論程式設計方法

作者：楊老師

如果你是初學者----------------請不要閱讀；

但有志成為中進階程式員--------請務必閱讀；

如果你是中級程式員------------請務必閱讀；

如果你進階程式員--------------請批評指正。

　　本文是我在“軟體工程師班”開學第一節課的講義，和“計算機軟體設計發展”講座上的内容整理而成。寫作本文的目的是引導學生從更高的層次來看待程式設計方法，為将來成為進階程式員而做好理論準備。

一、計算機硬體環境對軟體設計方法的限制

　　計算機的發明到現在已經60年了，計算機程式設計方法也伴随着計算機硬體技術的提高而不斷發展。硬體環境對軟體設計既有嚴重的制約作用，也有積極的推動作用。

　　在我的大學母校（此處删除6個字），數學系的一些老師，有幸成為了我國第一代的計算機DIY一族。呵呵，不要以為是組裝PC機呦，他們組裝的可是小型機。一人多高鐵皮櫃大小的主機，加上紙帶機（後期改進為讀卡機），組裝好後，除了供學校自己的科研使用外，還在全國各地銷售了十幾台。當時（七十年代）一台的售價是10幾萬元人民币，如果換算到今天，相當于價值大約為100多萬元，非常高檔的小型計算機了。下面大家猜猜，這麼高檔的計算機，它的記憶體是多少那？（都把嘴閉好了，我要公布答案了）—— 4K。

一塊50公分見方的記憶體闆，

插入到主機箱中，好了------ 1K；

再插一塊記憶體闆，好了------ 2K；

再插一塊記憶體闆，好了------ 3K；

再插一塊記憶體闆，好了------ 4K；

再......不行了，插不起了，太貴了！這就是當時的環境。這樣的環境下，用什麼寫程式那？當然隻有機器碼了。先用彙編寫，然後翻閱手冊手工改寫為機器碼，然後打卡或穿紙帶，輸入運作。可以想象，在當時的條件下，什麼叫好的程式那？什麼叫優秀的程式那？—— 技巧！

　　程式設計的最初始階段，是講究技巧的年代。如何能節省一個位元組，如何能提高程式運作的效率，這些都是要嚴肅考慮的問題。而所謂的程式的易讀性，程式的可維護性根本不在考慮範圍之内。

　　今天，35歲以上的學習過計算機的朋友可能都使用過一種個人計算機——APPLE-II（中國也生産過這種計算機的類似産品“中華學習機”）。主頻1M，記憶體48K（擴充後，最多可達到64K）。我就是使用這樣的計算機長大的 :)。當年，類似的個人計算機産品，還有PC1500，Layser310等。這種計算機上已經固化了 BASIC 語言，當然隻是為學習使用。要想開發出真正的商業程式，則必須使用彙編，否則的話，程式就比蝸牛還要慢了。于是，程式設計中對于技巧的運用，是至關重要的了。

題外話1：

　　比爾蓋茨是 BASIC 的忠實擁護和推動者。當年，他在沒有調式環境的狀況下，用彙編語言寫出了一款僅有 4K 大小的 BASIC 解釋器，且一次通過。确實另人佩服。（不象現在微軟出品的程式，動辄幾十兆。）這也許就是比爾對 BASIC 情有獨忠的原因，每當微軟推出（臨摹）一個新技術，則他會立刻在 BASIC 中提供支援。

題外話2：

　　在 APPLE-II 上有一款遊戲軟體“警察抓小偷”，當年熬夜玩遊戲，樂趣無窮。後來這款遊戲被移植到了PC上，咳~~~根本沒有辦法玩，因為小偷還沒跑就被警察抓到了。硬體的速度提升，另我無法再回味以前的時光了。

二、結構化程式設計

　　随着計算機的價格不斷下降，硬體環境不斷改善，運作速度不斷提升。程式越寫越大，功能越來越強，講究技巧的程式設計方法已經不能适應需求了。記得是哪本書上講過，一個軟體的開發成本是由：程式設計 30% 和程式維護 70% 構成。這是書上給出的一個理論值，但實際上，從我十幾年的工作經驗中，我得到的體會是：程式設計占 10%，而維護要占 90%。也許我說的還是太保守了，維護的成本還應該再提高。下面這個程式，提供了兩種設計方案，大家看看哪個更好一些那？

題目：對一個數組中的100個元素，從小到大排序并顯示輸出。(BASIC)

方法1：冒泡法排序，同時輸出。

FOR I=1 TO 100

FOR J=I+1 TO 100

IF A[I] > A[J] THEN T=A[J]: A[J]=A[I]: A[I]=T

NEXT J

? A[I]

NEXT I

方法2：冒泡法排序，然後再輸出。 FOR I=1 TO 100

FOR J=I+1 TO 100

IF A[I] > A[J] THEN T=A[J]: A[J]=A[I]: A[I]=T

NEXT

NEXT

FOR I=1 TO 100

? A[I]

NEXT

　　顯然，“方法1”比“方法2”的效率要高，運作的更快。但是，從現在的程式設計角度來看，“方法2”更進階。原因很簡單：（1）功能子產品分割清晰——易讀；（2）也是最重要的——易維護。程式在設計階段的時候，就要考慮以後的維護問題。比如現在是實作了在螢幕上的輸出，也許将來某一天，你要修改程式，輸出到列印機上、輸出到繪圖儀上；也許将來某一天，你學習了一個新的進階的排序方法，由“冒泡法”改進為“快速排序”、“堆排序”。那麼在“方法2”的基礎上進行修改，是不是就更簡單了，更容易了？！這種把功能子產品分離的程式設計方法，就叫“結構化程式設計”。

三、對程式設計中技巧使用的思考

　　我可以肯定，大家在開始學習程式設計的時候，一定都做過這樣一個題目：求100以内的素數。老師在黑闆上，眉飛色舞地寫出了第一個程式：（C程式）

方法1： for(i=1; i<100; i++)

{

for(j=2; j< i; j++)

if(i%j == 0) break;

if(j >= i) printf("%d,", i);

}

　　然後，老師開始批判這個程式“這個叫什麼呀？太慢了！因為我們都知道大偶數不可能是素數了，是以，要排除掉！” 于是，意尤未盡地寫出了第二個程式：

方法2： printf("2,");

for(i=3; i<100; i+=2)

{

for(j=2; j< i; j++)

if(i%j == 0) break;

if(j >= i) printf("%d,", i);

}

　　老師說：“看！我們隻改動了一點點，程式運作的速度就提高了一倍多”。然後運用誘導式教學法繼續提問“程式的效率，還能再提高嗎？能！”，得意地寫出第三個程式：

方法3： printf("2,");

for(i=3; i<100; i+=2) ''不考慮大偶數

{

for(j=3; j< i/2; j+=2) ''不考慮用偶數去測試，而且隻驗算到一半就足夠了

if(i%j == 0) break;

if(j >= i) printf("%d,", i);

}

　　“大家看，我們又隻改動了一點點，運作速度又提高了一倍多。可以了嗎？不可以！我們還能再提高”。于是又高傲地寫出了第四個程式：

方法4： printf("2,");

for(i=3; i<100; i+=2)

{

int k = sqrt(i);

for(j=3; j<= k; j+=2)

if(i%j == 0) break;

if(j >= k ) printf("%d", i);

}

然後，開始證明為什麼我們判斷素數的時候，隻需要驗算到平方根就足夠了：

　　假設p是合數，那麼令:p=a*b。反正法：由于我們已經判斷了p的平方根以内的整數都不能被p整除，于是 a>SQRT(p)。基于同樣的理由 b>SQRT(p)。于是 p = a * b > SQRT(p) * SQRT(p) = p 得出沖突， 命題得正。

　　的确，“方法4”的确比“方法1”的運作速度要提高了好幾倍，甚至好幾十倍。但我們仔細分析測試看看。

（1）“程式4”到底比“程式1”快了多少那？我在某台計算機上進行測試（P4，1.5G)得到的速度對比表：

計算範圍

100 1000 10000 100000

速度差 0.00秒 0.01秒 0.18秒 15秒

（2） 在10萬以上，才會看出一些差别。而這種差别根本就不夠底償程式設計階段的付出。如果計算的範圍再大，那麼不管是“方法1”，還是“方法4”都不是好的算法。（計算素數的另外一個比較優秀的算法叫“漏篩法”）

（3）寫出“方法1”，隻要具有國小四年級的數學水準就夠了，而“方法4”則需要國中三年級的水準并且還要具備一些“數論”的知識。

（4）從維護性看，如果你寫的程式需要另外一個程式員來維護，或者若幹時間以後，你重新來閱讀這段程式，那麼就會對這個程式産生很多疑問：這個求平方根是幹什麼用的？其實，就這個題目來說，使用到“方法3”就已經足夠了。

總結發言：

I. 計算機的價格每年下降一半，而運算速度每年提高一倍”，是以我們應該把速度提高的任務交給硬體實作。

II. 從易讀性、維護性出發，程式員隻負責按定義給出軟體實作。算法的問題是數學家解決的。

題外話：

　　多年以來，人們一直在尋找動态圖象(影視)的存儲和回放的算法，但效果都不理想。直到有人發現，原來在200多年前的數學家早就幫我們解決了這個問題——傅立葉（Fourier）級數展開。是以我要說，優秀的算法不是我們程式員要考慮的問題，我們的任務隻要按照數學家給出的算法翻譯為計算機程式語言而已。（這句話恐怕要遭到大多數程式員抛出的闆磚襲擊）再比如，計算一進制多次方程解的問題。我們使用的就是牛頓的疊代算法。不要怪我瞧不起你，你能發明這個方法的話，那就是當代的牛頓了。

四、程式的易讀性與書寫方法

　　程式是否容易閱讀和維護，與怎麼書寫有很大的關系。說實在的，C語言中為了友善程式員書寫，允許使用++,--,<<,&&，？......這些運算符号。但很多人經常亂用，以為自己寫的程式多麼簡潔，效率多高。其實，當你分行書寫的話則更加容易閱讀和維護，效率也不會降低，因為編譯程式早就幫你優化為最快捷的代碼了。先看一個簡單的例子：

計算一個整數乘 255(C語言)

方法1：a *= 255;

方法2：因為移位運算比乘法運算要快很多倍，是以a*255的運算書寫為：

a =(a<<8)-a; //a*255 = a*256 - a = (a<<8) - a

　　方法1的書寫非常簡單，直截了當，顯然更容易維護。而方法2的書寫運用了移位的技巧，不容易閱讀，但效率最高。是不是真的是這樣那？把這兩個程式編譯為彙編代碼看看。原來無論是方法1還是方法2，它們的彙編代碼都是一樣的：

mov ecx, eax

shl eax, 8

sub eax, ecx

　　也就是說，你認為非常技巧的書寫方法，其實編譯器的優化功能早就幫你想到了。那麼方法2的方式就很值得批判了。下面是幾個有關C語言書寫方面的重要原則：

　

盡量表達願義，多加注釋；

變量名稱和函數名稱，要使用有意義的符号，并且遵守“匈牙利命名法”；

不要為儉省記憶體，使一個變量在一個子產品中表達多個含義。

在某個子產品中，前半部分用i表示計數器，由于後半部分不再使用計數器了，于是又用i來儲存某個中間的結果。等你維護這段程式的時候，保證你肯定會犯傻的。

在使用條件表達式的時候，不要混合書寫運算表達式；

經常有人在書寫for循環的時候，使用這樣的方式： for(int a=1,s=0; a<=100 && (s+=a); a++);

天呀，這樣寫是不會提高程式運作效率的，尤其是當運算表達式複雜的時候，就更不容易閱讀了，還是把運算寫到for的循環體中吧。 int s = 0;

for(int a=1; a<=100; a++)

s += a; //計算1+2+...+100 這不很好嗎?!

再比如，if(a=b)這個寫法在文法上是允許的，但不要使用。要使用也要if(0!=(a=b))這樣的方式。 還有值得一提的是慎用“,”（逗号運算符）。

不要連續使用++,--,<<，*，& .....這樣的運算符号。

a = b++-(--c<<1+e&0x0f>>1); //這個人有病。出這個題目考試的老師，也有病。

常量要寫在條件表達式的左邊；

if(5 == a) 這是正确的寫法，這樣書寫可以避免勿輸入而導緻的 if(a=5)這樣的錯誤。

避免程式中{ }的嵌套層次太深；

最多4層。如果必須大于4層，那麼寫成調用子函數或宏的方式。

盡量多地使用斷言；

當你在書寫程式的過程中，憑你的智慧，你一定是知道：程式運作到我正書寫的這行代碼的時候某個變量一定是某個值。好啦，那麼不要憂郁，馬上加上一句代碼：ASSERT(nnn == xxx);。将來在調式維護這段代碼的時候，你會得到無限美妙的回報。

書寫需要“成對比對”使用的代碼的時候，在寫使用代碼之前，就先把結束寫出來；

file.Open(...); //當要打開檔案的時候 char *lp=new char [100]; //當要申請記憶體的時候

...... //先不要寫這段代碼 ...... //先不要寫這段代碼

file.Close(); //馬上寫關閉 delete [] lp; //馬上寫釋放

xxx.Loack(); //當某個對象需要鎖定的時候 for(....)

...... //先不要寫這段代碼 { //寫大括号的時候

xxx.Unlock(); //馬上寫解鎖 } //馬上寫大括号結束

和這個道理相同，在C++的類中，如果需要申請記憶體，那麼先在構造函數中給出 lp=NULL;然後馬上在析構函數中書寫 if(lp) delete []lp;

可以适當地使用goto；

在結構化程式設計中，goto 是被排斥的。但是，如果适當地使用 goto 不但不影響斜率，而且還能提高程式的可讀性。

題目：合并2個檔案到一個新檔案中。（不要挑我的毛病呀~~~~~，我使用的是類C的方式書寫的。）

方法1：

FILE *f1,*f2,*f3;

if(Open(f1)成功)

{

if(Open(f2)成功)

{

if(Open(f3)成功)

{

...... //這裡是真正幹活的地方

Close(f1);

Close(f2);

Close(f3);

}

else //f3不成功

{

Close(f1);

Close(f2);

......

}

}

else //f2不成功

{

Close(f1);

......

}

}

else //f1不成功

{

......

}

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

方法2：FILE *f1=NULL,*f2=NULL,*f3=NULL;

if(Open(f1)不成功) goto err;

if(Open(f2)不成功) goto err;

if(Open(f3)不成功) goto err;

...... //這裡是真正幹活的地方

err:

if(f3) Close(f3);

if(f2) Close(f2);

if(f1) Close(f1);

　　方法1是最最标準的結構化設計，好嗎？不好！尤其是當{ }的層次比較深的時候，估計你尋找真正幹活的代碼的地方都找不到。而使用方法2的程式，不但程式容易讀，而且沒有{ } 的深度。在C++中，又提供了異常try/catch的設計結構，而異常的結構則比 goto 的結構更好、更完善了。

五、面向對象的程式設計

　　随着程式的設計的複雜性增加，結構化程式設計方法又不夠用了。不夠用的根本原因是“代碼重用”的時候不友善。面向對象的方法誕生了，它通過繼承來實作比較完善的代碼重用功能。很多學生在應聘工作，面試的時候，常被問及一個問題“你來談談什麼是面向對象的程式設計”，學生無言，回來問我，這個問題應該怎麼回答。我告訴他，你隻要說一句話就夠了“面向對象程式設計是對資料的封裝；範式（模闆）的程式設計是對算法的封裝。”後來再有學生遇到了這個問題，隻簡單的一句對答，對方就對這個學生就刮目相看了（學生後來自豪地告訴我的）。為什麼那？因為隻有經過徹底的體會和實踐才能提煉出這個精華。

　　面向對象的設計方法和思想，其實早在70年代初就已經被提出來了。其目的就是：強制程式必須通過函數的方式來操縱資料。這樣實作了資料的封裝，就避免了以前設計方法中的，任何代碼都可以随便操作資料而因起的BUG，而查找修改這個BUG是非常困難的。那麼你可以說，即使我不使用面向對象，當我想通路某個資料的時候，我就通過調用函數通路不就可以了嗎？是的，的确可以，但并不是強制的。人都有惰性，當我想對 i 加1的時候，幹嗎非要調用函數呀？算了，直接i++多省事呀。呵呵，正式由于這個懶惰，當程式出BUG的時候，可就不好捉啦。而面向對象是強制性的，從編譯階段就解決了你懶惰的問題。

　　巧合的是，面向對象的思想，其實和我們的日常生活中處理問題是吻合的。舉例來說，我打算丢掉一個茶杯，怎麼扔那？太簡單了，拿起茶杯，走到垃圾桶，扔！注意分析這個過程，我們是先選一個“對象”------茶杯，然後向這個對象施加一個動作——扔。每個對象所能施加在它上面的動作是有一定限制的：茶杯，可以被扔，可以被砸，可以用來喝水，可以敲它發出聲音......；一張紙，可以被寫字，可以撕，可以燒......。也就是說，一旦确定了一個對象，則方法也就跟着确定了。我們的日常生活就是如此。但是，大家回想一下我們程式設計和對計算機的操作，卻不是這樣的。拿DOS的操作來說，我要删除一個檔案，方法是在DOS提示符下：c:> del 檔案名<回車>。注意看這個過程，動作在前（del），對象在後(檔案名),和面向對象的方法正好順序相反。那麼隻是一個順序的問題，會帶來什麼影響那？呵呵，大家一定看到過這個現象：File not found. “啊~~~，我錯了，我錯了，檔案名敲錯了一個字母”，于是重新輸入：c:> del 檔案名2<回車>。不幸又發生了，計算機報告：File read only. 哈哈，痛苦吧:)。是以DOS的操作其實是違反我們日常生活中的習慣的（當然，以前誰也沒有提出過異議），而現在由于使用了面向對象的設計，那麼這些問題，就在編譯的時候解決了，而不是在運作的時候。obj.fun()，對于這條語句，無論是對象，還是函數，如果你輸入有問題，那麼都會在編譯的時候報告出來，友善你修改，而不是在執行的時候出錯，害的你到處去捉蟲子。

　　同時，面向對象又能解決代碼重用的問題——繼承。我以前寫了一個“狗”的類，屬性有（變量）：有毛、4條腿、有翹着的尾巴（耷拉着尾巴的那是狼）、鼻子很靈敏、喜歡吃肉骨頭......方法有（函數）：能跑、能聞、汪汪叫......如果它去抓耗子，人家叫它“多管閑事”。好了，狗這個類寫好了。但在我實際的生活中，我家養的這條狗和我以前寫的這個“狗類”非常相似，隻有一點點的不同，就是我的這條狗，它是：卷毛而且長長的，鼻子小，嘴小......。于是，我派生一個新的類型，叫“哈巴狗類”在“狗類”的基礎上，加上新的特性。好了，程式寫完了，并且是重用了以前的正确的代碼——這就是面向對象程式設計的好處。我的成功隻是站在了巨人的肩膀上。當然，如果你使用VC的話，重用最多的代碼就是MFC的類庫。

六、元件（COM）程式設計

　　有了面向對象程式設計方法，就徹底解決了代碼重用的問題了嗎？答案是：否！硬體越來越快，越來越小了，軟體的規模卻也越來越大了，集體合作越來越重要，代碼重用又出現的新的問題。

我用C++寫的類，不能被BASIC重用——不能誇語言；

你要幹什麼，想重用我的代碼？不行，這樣你就看見了我的設計思想——隻能在源程式級别重用，不能在二進制級别（可執行代碼及）重用；

我耗盡畢生的精力，寫了一個包羅萬象的類庫，但沒有人用。因為他們說：你這個太大了，我的程式隻有1K，你卻給我一個 10000MB 的庫——MFC 的尴尬；

太好了，我終于找到了程式中的一個BUG，已經修改完成，而且是隻改動了一個位元組。接下來我要重新向我的使用者分發新的版本，我的使用者有......10萬個——更新的非魯棒性，不是我分發累死了，就是使用者重新安裝累死了。（魯棒：robust。意為強壯性的，平順的，順滑的.....鬼知道是哪個不懂計算機的人翻譯的這個詞彙。）

我想寫一個集大成的軟體，這個軟體的功能是我中有你，你中有我。既能實作文字編輯，又能實作電子表格計算，又能實作自動翻譯，還能畫圖，還能實作資料庫檢索，還可以看電影.....隻要用了我的這個軟體，想要什麼就有什麼，我要強占整個軟體的市場------OLE實作的重用功能，隻要學會了COM，這些都不是問題了；

使用者甲要求我的軟體視窗上下分割，使用者乙要求我的軟體視窗左右分割......我需要在我的軟體基礎上，派生出100個類型，可怎麼辦呀？将來怎麼維護呀？------在腳本的支援下，實作同一程式的的靈活配置而重用，問題迎刃而解了；

我是個老闆，你知道我有多痛苦嗎？我手下的員工向我提出加工資的要求，我不得不答應呀。因為如果這個員工跳槽了，他的代碼要維護起來有多難！！！——現在好啦，我要求員工統統用元件寫子產品，想加工資？門都沒有，威脅我要走？那你走吧，這個月的工資也不發了。反正用元件寫的代碼，我可以很容易地進行包容和聚合實作維護。（老闆的福音，程式員的悲哀）；

還有好多那，現在想不起來了......

　　COM程式設計方法，就是解決以上問題的一個方式。有很多朋友覺得COM非常複雜難懂，不想學習了。你一定學習過程式設計的最基本的方法（非結構化設計：彙編、gwBasic......）,然後，你又學習了結構化程式設計（C、Pascal......）,然後，你又努力學習并熟練掌握了面向對象的程式設計方法（C++、Delphi、Java......）,那麼不要怕，要有信心去學習元件程式設計，它隻是一個設計方法和思想，并且是目前較進階的方法，如果不掌握，就太可惜了。

學習了結構化程式設計，你就會“藐視”那些不遵守結構化設計思想而寫出的代碼；

學習了面向對象設計，你就會“嘲笑”那些為找BUG而暈頭轉向的程式員；

同樣，學習了元件程式設計，你就會站在更高的層次看待程式設計。

七、結束語

　　寫程式的目的是什麼？養家糊口、興趣使然、我的事業......這些都對。但我要強調的是：寫程式的目的是為了修改程式。在這個觀點上，那麼寫注釋、寫文檔、選擇語言、選擇結構......都是為這個服務的。本文從軟體設計方法的進化角度來反複闡述這個觀點，希望愛好者能有所體會和思考。

文中所讨論的技術和觀點，适合于大多數情況下的程式設計，而對于特殊的應用的（驅動開發，嵌入式開發，網絡通訊，實時視訊......），這些領域中，由于硬體環境的限制和極限效率的要求，有些觀點就不合适了，需要具體情況具體分析。另外就是對于程式設計的初學者，可以先不考慮這麼多問題，以掌握基本技巧方法和思想為要。

歡迎大家批評指正。文中一些調侃的部分，也請勿對号入坐^_^。

[align=left][size=1][color=#cccccc][Edit on 2005-1-23 16:48:56 By zbkid][/color][/size][/align]

By [zbkid] at 16:59:57 | Comments[0] | 36 views

 對程式設計初學者的忠告  [2005-1-15]

作為一名自考生，我覺得除了考過每一門課外，還有一些理念需要學習：

　　我始終認為，對一個初學者來說，IT界的技術風潮是不可以追趕的，而且也沒有能力去追趕。我時常看見自己的DDMM們把課本扔了，去賣些價格不菲的諸如C#, VB.Net這樣的大部頭，這讓我感到非常痛心。而許多搞不清指針是咋回事的BBS站友眉飛色舞的讨論C#裡面可以不用指針等等則讓我覺得好笑。C#就象當年的ASP一樣，“忽如一夜春風來，千樹萬樹梨花開”，結果許多學校的資訊學院成了“Web學院”。96,97級的不少大學生都去做Web了。當然我沒有任何歧視某一行業的意識。我隻是覺得如果他們把追趕這些時髦技術的時間多花一點在基礎的課程上應該是可以走得更遠的。

　　幾個誤區

　　初學者對C#風潮的追趕其實也隻是學習過程中經常遇到的幾個誤區之一。我将用一些實際的例子來說明這些現象，你可以按部就班的看看自己是不是屬于其中的一種或者幾種：

　　認為計算機技術等于程式設計技術:

　　有些人即使沒有這個想法，在潛意識中也有這樣的沖動。讓我奇怪的是，許多資訊學院的學生也有這樣的念頭。認為計算機專業就是程式設計專業，與程式設計無關的，或者不太相關的課程他統統都不管，極端的學生隻要書上沒帶“程式設計”兩個字他就不看。

　　其實程式設計隻是計算機技術應用過程中一種複雜性最低的勞動，這就是為什麼IT業最底層的人是程式員（CODER）。計算機技術包括了多媒體，計算機網絡，人工智能，模式識别，管理資訊系統等等這些方面。程式設計工作隻是在這些具體技術在理論研究或者工程實踐的過程中表達算法的過程。程式設計的人不一定對計算機技術的了解就一定很高。而一個有趣的現象是，不少大師級的計算機技術研究者是不懂程式設計的。網上的炒作和現實中良好的工作待遇把程式設計這種勞動神秘化了。其實每一個程式員心裡都明白，自己這些東西，學的時候并不比其它專業難，是以自然也不會高檔到哪裡去。

　　咬文嚼字的孔已己作風:

　　我見過一本女生的《計算機網絡原理》教材，這個女生象國小生一樣在書上劃滿了橫杠杠，筆記做得滿滿的，列印出來一定比教材還厚。我不明白的是，象計算機網絡原理這樣的課程有必要做筆記？我們的應試教育的确害了不少學生，在上《原理》這一類課程的時候許多學生象學《馬列原理》一樣逐字背誦記憶。這乃是我見過的最愚蠢的行為。所謂《原理》，即是需要掌握它為什麼這樣做，學習why，而不是how（怎樣做）。極端認真的學生背下以太網的網線最大長度，資料幀的長度，每個字段的意義，IP報頭的格式等等，但是忘了路由的原則，忘了TCP/IP協定設計的宗旨。總之許多人花了大量的時間把書背得滾瓜爛熟卻等于什麼也沒學。

　　在學習程式設計的時候這些學生也是這樣，他們确切的記得C++文法的各個細節。看完了C++教程後看《Thinking in C++》（确實是好書），《Inside C++》，《C++ reference》，this C++, that C++……，然後是網上各種各樣的關于C++文法的奇聞逸事，然後發現自己又忘了C++的一些文法，最後回頭繼續惡補…。有個師弟就跟我說：“C++太難了，學了這裡忘了那裡，學了繼承忘了模闆。”我的回答道：“你不去學就容易了”。我并沒有教壞他，隻是告訴他，死摳C++的文法就和孔已己炫耀茴香豆的茴字有幾種寫法一樣毫無意義。你根本不需要對的C++文法太關心，動手程式設計就是了，有不記得的地方一查MSDN就立馬搞定。我有個結論就是，實際的開發過程中對程式文法的了解是最微不足道的知識。這是為什麼我在為同學用Basic（我以前從沒有學過它）寫一個小程式的時候，隻花了半個小時看了看文法，然後再用半個小時完成了程式，而一個小時後我又完全忘記了Basic的所有關鍵字。

　　不顧基礎，盲目追趕時髦技術：

　　終于點到題目上來了。大多數的人都希望自己的東西能夠馬上跑起來，變成錢。這種想法對一個已經進入職業領域的程式員或者項目經理來說是合理的，而且IT技術進步是如此的快，不跟進就是失業。但是對于初學者來說（尤其是時間充裕的大中專在校生），這種想法是另人費解的。一個并未進入到行業競争中來的初學者最大的資本便是他有足夠的時間沉下心來學習基礎性的東西，學習why而不是how。時髦的技術往往容易掌握，而且越來越容易掌握，這是商業利益的驅使，為了最大化的降低軟體開發的成本。但在IT領域内的現實就是這樣，越容易掌握的東西，學習的人越多，而且淘汰得越快。每一次新的技術出來，都有許多初學者跟進，這些初學者由于缺乏必要的基礎而使得自己在跟進的過程中花費大量的時間，而等他學會了，這種技術也快淘汰了。基礎的課程，比方資料結構，*作系統原理等等雖然不能讓你立馬就實作一個linux（這是許多人嘲笑理論課程無用的原因），但它們能夠顯著的減少你在學習新技術時學習曲線的坡度。而且對于許多關鍵的技術（比方Win32 SDK程式的設計，DDK的程式設計）來說甚至是不可或缺的。

　　如果你是學生，或者如果你有充足的時間。我建議你仔細的掌握下面的知識。我的建議是針對那些希望在IT技術上有所成就的初學者。同時我還列出了一些書目，這些書應該都還可以在書店買到。說實在的，我在讀其他人的文章時最大的心願就是希望作者列出一個書單。

　　大學英語－不要覺得好笑。我極力推薦這門課程是因為沒有專業文檔的閱讀能力是不可想象的。中文的翻譯往往在猴年馬月才會出來，而現在的許多出版社幹脆就直接把E文印刷上去。學習的方法是強迫自己看原版的教材，開始會看不懂，用多了自然熟練。吃得苦下得狠心絕對是任何行業都需要的品質。

　　計算機體系結構和彙編語言－關于體系結構的書遍地都是，而且也大同小異，倒是彙編有一本非常好的書。《80x86彙編語言程式設計教程》（清華大學出版社，黑色封面，楊季文著）。你需要着重學習386後保護模式的程式設計。否則你在學習現代作業系統底層的一些東西的時候會覺得是在看天書。

　　計算機作業系統原理－我們的開發總是在特定的作業系統上進行，如果不是，隻有一種可能：你在自己實作一個作業系統。無論如何，作業系統原理是必讀的。這就象我們為一個晶片制作外圍裝置時，晶片基本的工作時序是必需了解的。這一類書也很多，我沒有發現哪一本書非常出衆。隻是覺得在看完了這些書後如果有空就應該看看《Inside Windows 2000》(微軟出版社，我看的是E文版的，中文的書名想必是Windows 2000技術内幕之類吧)。

　　資料結構和算法－這門課程能夠決定一個人程式設計水準的高低，是一門核心課程。我首選的是清華版的（朱戰立，劉天時）。很多人喜歡買C++版的，但我覺得沒有必要。C++的文法讓算法實作過程變得複雜多了，而且許多老師喜歡用子產品這一東西讓算法變得更複雜。倒是在學完了C版的書以後再來浏覽一下C++的版的書是最好的。

　　軟體工程－這門課程是越到後來就越發現它的重要，雖然剛開始看時就象看馬哲一樣不知所雲。我的建議是看《實用軟體工程》（黃色，清華）。不要花太多的時間去記條條框框，看不懂就跳過去。在每次自己完成了一個軟體設計任務（不管是練習還是工作）以後再來回顧回顧，每次都會有收獲。

　　Windows程式設計－《北京大學出版社，Petzold著》我建議任何企圖設計Windows程式的人在學習VC以前仔細的學完它。而且前面的那本《Inside Windows 2000》也最好放到這本書的後面讀。在這本書中，沒有C++，沒有GUI，沒有控件。有的就是如何用原始的C語言來完成Windows程式設計。在學完了它以後，你才會發現VC其實是很容易學的。千萬不要在沒有看完這本書以前提前學習VC，你最好碰都不要碰。我知道的許多名校甚至都已經用它作為教材進行授課。可見其重要。

　　上面的幾門課程我認為是必學的重要課程（如果你想做Windows程式員）。

　　對于其它的課程有這樣簡單的選擇方法：如果你是計算機系的，請學好你所有的專業基礎課。如果不是，請參照計算機系的課程表。如果你發現自己看一本書時無法看下去了，請翻到書的最後，看看它的參考文獻，找到它們并學習它們，再回頭看這本書。如果一本書的書名中帶有“原理”兩個字，你一定不要去記憶它其中的細節，你應該以一天至少50頁的速度掌握其要領。盡可能多的在計算機上實踐一種理論或者算法。

　　你還可以在CSDN上閱讀到許多書評。這些書評能夠幫助你決定讀什麼樣的書。

　　日三省乎己

　　每天讀的書太多，容易讓人迷失方向。一定要在每天晚上想想自己學了些什麼，還有些什麼相關的東西需要掌握，自己對什麼最感興趣，在一本書上花的時間太長還是不夠等等。同時也應該多想想未來最有可能出現的應用，這樣能夠讓你不是追趕技術潮流而是引領技術潮流。同時，努力使用現在已經掌握的技術和理論去制作具有一定新意的東西。堅持這樣做能夠讓你真正成為一個軟體“研發者”而不僅僅是一個CODER。

　　把最多的時間花在學習上

　　這是對初學者最後的忠告。把每個星期玩SC或者CS的時間壓縮到最少，不玩它們是最好的。同時，如果你的ASP技術已經能夠來錢，甚至有公司請你兼職的話，這就證明你的天份能夠保證你在努力的學習之後取得更好的收益，你應該去做更複雜的東西。眼光放長遠一些，這無論是對誰都是适用的。

[Edit on 2005-1-15 0:09:23 By zbkid]

By [zbkid] at 0:07:07 | Comments[0] | 41 views

 程式寶典：C++學習感想  [2005-1-14]

【簡 介】

　　很多新手特别容易會對自己所學習的東東産生疑惑、迷茫。覺得自己學這個東西，花了這麼多時間有沒有用，會不會過時？這種思想很普遍。

　　在一些論壇上經常會看到一些各語言的優劣比較，知道自己所學語言的優劣也好，但是如果一味停留在這個層面就沒有用了。任何語言都隻是工具而已。重要的是使用工具的人！就我個人的經驗來講，真正處于業界搞開發的人都願意使用成熟的、為自己所熟知的技術來完成工作。而新手都喜歡用一些比較新的技術來做開發，而且喜歡追求新奇（從界面很容易看出來，花花綠綠的界面多半出自新手）。其實，安于用一些效率可能低下、擴充性和維護性差的方法來解決問題并不是開發人員的錯。他們隻是在完成工作而已。但是作為一個真正有上進心的開發人員，我們應該使用更優雅和高效的程式設計技術，這才是我們逐漸變成程式設計“大牛”的好習慣。老是停留在原地，很容易被淘汰的。在軟體開發這個行當，尤其如此。無論是對學生，還是一線開發人員，我覺得都不應該産生“書讀夠了”的感歎！我有時候喜歡将以前看過的書翻出來再看，每次總能體會到一些新東西。有關C＋＋語言的書籍更是如此，而且我覺得我所起的題目不是很好。為什麼？因為我覺得學習語言還隻是新手跨入軟體開發“地獄”的第一步，單單學習語言本身是遠遠不夠的，還要學習相關的程式庫（C++當然首選是先學習C＋＋标準程式庫）、相關的平台技術（如.NET），說得更遠一點，還要鍛煉對目标問題的分析、歸納能力等等。工作之前，技術路線自己作主，工作之後，絕大多數程式員将被公司技術路線左右。是以，趁現在還有時間，可以學一些自己感興趣的。如果想搞軟體開發，特别是電力系統軟體的開發，學好C＋＋不會令我們失望。當我們進入C＋＋的前門，然後經過一段黑暗之路，再從後門出來到達光明頂後，我們會體味到“一覽衆山小”的感覺。　

　　推薦書籍:　　

　　《程式設計高手箴言》---------- 梁肇新（用過超級解霸的都應該知道吧，^_^）寫的第一本書，其中有幾章還是值得一讀的。在這本書中，梁告訴我們，學東西要耐心，要耐得住“寂寞”，走自己的路，讓别人去“說”吧！

　　最近比較忙，原來打算緊扣主題講講一些具體的C＋＋語言的細節的，但還是抽不出大段的時間了。是以，現在隻能再漫談一些關于C＋＋的故事了。

　　C＋＋源于C語言，還記得很久以前學習C語言的時光（那是一段快樂而充實的時光），可是現在學習C＋＋，并不是在C的基礎上加上了類而已，如果這樣認為，我們是耍不好C＋＋的。是以，C＋＋絕不是C的更新或擴充，我們應該把C＋＋當作一門新語言來學習（C＋＋之父Bjarne Stroustrup語）。

　　寫程式首先希望是程式能正确執行，其次是效率能夠被接受，再次就是易于維護。C＋＋是一個難學易用的語言。C＋＋提供了太多可選擇的東西，而且使用使用C＋＋來寫程式可以有四種思考模式：基于過程、基于對象、面向對象和泛型。我們使用一種語言來寫程式，并不意味着就是使用語言本身，換句話說，我們更多的時候是使用程式庫在寫程式。比如MFC、STL、ATL、VCL等等。其中要使用C＋＋來寫出結構優美、性能卓越、代碼簡潔、易于維護的代碼，首推C＋＋标準程式庫。STL對效率做了嚴格的要求，而且使用STL寫出來的程式簡潔美觀（前段時間我特意貼了一個要求對若幹整數進行排序的文章，其實目的就是用來展示STL的簡潔優雅）。一旦習慣使用泛型思維來考慮問題，我們能夠充分體會到模闆帶來的美！對于數值計算來說，C＋＋标準程式庫可以充分滿足現代化服務和商業計算對資料、資訊的即時回應的要求。

　　我覺得學好一門語言最重要的就是實踐。也就是多“寫”！“工程經驗之積累”對已具有一段開發時間的程式員而言，非常重要！隻有在不斷的積累中，我們才能漸漸體會到C＋＋語言中的一些背後的東西。對于這點，沒有大量程式代碼寫作經驗的菜鳥，也可以借助《Effective C++》先攢一些經驗值。《Effective C++》是一本好書！。Meyers的書絕對值得一讀，Meyers可以說當今C＋＋社群中數一數二的技術專家。　　

　　推薦網站：www.royaloo.com

　　C++提供了操作符new來在堆上配置設定記憶體，操作符delete來釋放記憶體。有些情況下，我們需要對記憶體的配置設定和釋放進行更好的控制。許多程式建立和釋放一些重要類的大量的對象，如tree nodes,linked lists links,points,lines,messages,etc.使用通用的記憶體配置設定器如new和delete來進行這些對象的配置設定和釋放有時将支配程式的運作時間和記憶體需求。　　

　　兩方面的因素：通用記憶體配置設定操作的運作和空間的耗費以及不同對象大小引起的記憶體碎片。類使用定制的記憶體配置設定器将加快模拟器、編譯器和類似程式的執行速度。

　　例外一種需要更好的記憶體控制的情況是：需要在有限資源的情況下長時間不間斷運作的程式。實時系統經常需要用最少的耗費來擷取有保證的可預期的記憶體。這也就導緻了更好的記憶體控制的需要。一般來說，這些程式都避免使用動态的記憶體配置設定，而使用特殊目的的記憶體配置設定器來管理有限資源。

　　此外，還有一些情況下由于硬體或系統的要求，需要将對象放在指定的記憶體位置。這也需要進行定制的記憶體管理(通過重載new來加以實作)。

　　在C++ Release 2.0中，為了滿足以上需求，記憶體管理機制做了相應的修改。主要是引進了operator new [] 和 operator delete []。　　

　　new操作符的作用範圍（Scope for operator new Functions）

　　操作符(Operator) 範圍(Scope)

　　::operator new Global

　　class-name::operator new Class 　　

　　operator new的第一個參數必須是類型size_t（在STDDEF.H中定義的類型），傳回類型

　　為void *。

　　當配置設定内建(built-in）類型的對象、未包含使用者自定義的new操作符函數的類對象、任何類型的數組時，使用全局new操作符函數。當在類中自定義new操作符時，配置設定該類對象的記憶體時，調用該類的new操作符。如下：　

　　#include

　　#include

　　class Blanks

　　{

　　public:

　　Blanks(){}

　　void *operator new( size_t stAllocateBlock, char chInit );

　　};

　　void *Blanks::operator new( size_t stAllocateBlock, char chInit )

　　{

　　void *pvTemp = malloc( stAllocateBlock );

　　if( pvTemp != 0 )

　　memset( pvTemp, chInit, stAllocateBlock );

　　return pvTemp;

　　}

　　int main()

　　{

　　Blanks *a5 = new( 0xa5 ) Blanks;//建立對象Blanks，并且初試化為0xa5

　　return a5 != 0;

　　}

　　new操作符可以重載，而delete卻不行。因為等到需要釋放的時候，我們所能得到的就是一個指針。而且該指針可能不是原先的對象類型指針（有可能進行了類型轉換）。實際上，當使用new獲得一個指向一片記憶體的指針時，在該片記憶體前有一個訓示器(indicator)，記錄實際配置設定的記憶體數量。當調用delete時，可以獲知需要釋放的記憶體大小。數組的釋放(Deallocating Arrays):　

　　void f( )

　　{

　　X* p1 = new X[10];

　　//...

　　delete [] X;

　　}

　　為什麼不使用delete [10] X;來釋放記憶體？Bjarne Stroustrup稱這種做法容易導緻錯

　　誤，而将記錄元素個數的任務放在delete的實作中了。

　　至于為什麼C++中未内建垃圾收集器(Garbage Collection)的原因，看《C＋＋語言的設計和演化》(En) Bjarne Stroustrup 機械工業出版社（俗稱：D&E）可以得到答案。

　　此外，C＋＋标準庫中提供了一種智能型指針auto_ptr,這種指針可以幫助我們防止“被異常抛出時發生資源洩漏”。但是缺點是該智能型指針不能指向數組，因為其内部釋放記憶體是通過delete而非delete [] 來進行的。是以，隻能使用其來指向一個單個對象。

　　模闆部分是C＋＋中比較難的部分，也是C＋＋的魅力所在。以下文字是我以前看過的，具體出處不清楚了。今天稍微整理了一下，作為模闆介紹的一個單元。

By [zbkid] at 21:44:59 | Comments[0] | 36 views

 [轉]寫給想當程式員的朋友 -- 一個還不太老的程式員的體會  [2004-12-28]

寫給想當程式員的朋友 -- 一個還不太老的程式員的體會

--------------------------------------------------------------------------------

作者:風化

軟體以程式員為本 - -《程式員》

謹以此文獻給所有想當程式員的朋友

（一） 文章由來及個人經曆

我是一名計算機專業的大學畢業生，畢業已經1年多了。畢業後從事的是軟體程式設計工作，經常有其他專業的朋友想從事軟體程式設計工作，向我請教如何，因為我自覺涉行不深，不敢信口開河，無奈朋友信任，我不得不鄭重考慮一下這個問題了，來幫助朋友選擇和回報朋友的信任。

這也就是此文的由來。

還是先談談我個人的經曆吧。（是不是有點俗套，但我覺得了解我的經曆，有助于了解我話的含義；我一向認為不了解古龍的生活經曆的，不會真正讀懂古龍的作品和古龍筆下的英雄的）我大學就讀于南方一所著名的高校（因為自己的不成氣，愧談母校名謂），學的就是計算機專業。上大學時，幾乎沒有認真的聽完一門專業課程，上課看報紙睡大覺，下課看錄像看小說看球賽，臨考抱佛腳，每次考試和課程設計都是蒙混過關。（于之相對是，我選修的工商管理和經濟貿易方面的課到是聽得不亦樂乎，考的分數頗高，也許這才是我的真正興趣所在。）

總而言之，大學是混過來了，對專業的了解和掌握程度，應該沒有達到畢業要求的合格水準。（也很後悔，但是有什麼用呢，當時不知道珍惜；如果上天再給我一次機會的話，我一定會抓住，多看點美國大片少看點港片；現在，重回校園是我的一大理想）但是大學的學習使我有了一個簡單的知識架構（總算學費沒白交），我對一個朋友這樣形容過我的這個知識架構，“它不是鋼筋鑄的，是稻草紮的”，哈哈哈，不要笑，真的，我敢說很多大學畢業的朋友的本專業的知識架構也隻不過是“稻草紮的”。直到現在，我一直覺得自己的基礎知識還是很薄弱，一直想抓點時間，把基礎書本好好的溫習一下。（此項任務正在計劃和實施中）

畢業後，配置設定到某研究所工作。當上司讓我選擇自己以後的工作方向時，我毫不猶豫的選擇了軟體（也不知道到底是對還是錯，但我決不後悔）。此研究所主要是以硬體為核心搞通信控制裝置的研發生産；軟體是輔助，是以也不受什麼重視，很多搞軟體的人都跳槽走了，留下來的大都是一些已經廢掉和行将廢掉的“僞/萎”程式員（名副其實的“軟體人員”）。在這裡感覺不到什麼高緊張和高技術程度的研究和開發；軟體開發的技術含量極低，以緻于大部分人隻有半年的學習和開發經驗，以後都是這些知識和經驗的重複利用。（我問過其他到研究所工作的同學，他們說都一樣，嗚呼，我們的國防科研開發呀）對于軟體的開發，上司的意志和老掉牙的經驗在新課題的技術采用和開發中起了決定性作用，沒有明确的需求，沒有明确的開發計劃和進度，大家在一天一天一周一周的浪費着寶貴的時間，最後開發出來的東西修來改去，直至它變成垃圾。 我越來越認識到一點，要麼象那些廢人一樣廢掉，要麼自己去努力尋求出路，反正别指望從工作中得到什麼高明的經驗了（教訓倒也許有）。期間發生了一些感情上的糾紛，嚴重的影響了學習計劃和效果，直到現在浮躁的心仍然有些浮躁。

期間，我讀了一些書，看了一些文章，編過一些小例程，搞了一些沒有什麼技術含量的開發工作，也和一些前輩和高手們談過聊過。 我一直在思考幾個問題；如何學習軟體開發？如何搞軟體開發，國外的軟體開發到底其秘訣在何處？為何我們的軟體業一直在低水準徘徊？我們難道真的離了Microsoft就活不了？我們的程式員到底在浪費時間幹些什麼？軟體開發到底是如何分類的？我們如何走自己的民族軟體之路？

我想了很久，一些想通了，一些還在想。但我知道有一點是肯定的，那就是我們一定要靠我們自己走出自己的軟體之路！跟在别人屁股後面永遠受制于人！

好了，關于經曆和牢騷就先寫這些吧，該進入我們的正題了。

（二） 你适合當程式員嗎，你知道程式設計式是怎麼回事嗎？

1、 程式員意味着要程式設計式。（如果你僅僅想得到一份高薪水的工作，喝喝咖啡就等老闆發薪水，我奉勸你還是另找一份更合适的工作，譬如練攤，真的，兄弟，這份工作不适合你）

2、你是學文的還是學理的，程式設計式也許需要浪漫，但更需要邏輯和嚴謹。（說坦白點就是，在你沒有找到樂趣以前，它很枯燥）

3、你有對新技術追求的熱情嗎？你有刨根問底的探索精神嗎？（熱情絕對是最重要的！你仔細思考一下自己的性格适合當程式員嗎？）

4、當程式員決不是什麼好差事，時刻需要學習，需要思考。（直到你成為那個可以引導别人去學習和思考的人，你才可以偷偷的嘿嘿笑，又一群傻蛋）

5、程式員的未來很迷茫。（但我認為關鍵看你自己！我希望你是一個有追求的人，不僅僅是混碗飯吃。因為真正的樂趣在于創造；如果你能改變軟體業的曆史，那才是英雄；不想成為Bill Gates，不想成為Dennis Ritchie和 Bjarne Stroustrup，我會說你沒有追求。有個關于程式員未來的笑話，也許你還沒聽過，你該聽一聽，摘抄如下：

一個程式員對自己的未來很迷茫，于是去問上帝。

“萬能的上帝呀，請你告訴我，我的未來會怎樣？”

上帝說“我的孩子，你去問Lippman，他現在上司的程式員的隊伍可能是地球上最大的”

于是他去問Lippman。

Lippman說“程式員的未來就是駕馭程式員”

這個程式員對這個未來不滿意，于是他又去問上帝。

“萬能的上帝呀，請你告訴我，我的未來會怎樣？”

上帝說“我的孩子，你去問Gates，他現在所擁有的财産可能是地球上最多的”

于是他去問Gates。

Gates說“程式員的未來就是榨取程式員”

這個程式員對這個未來不滿意，于是他又去問上帝。

“萬能的上帝呀，請你告訴我，我的未來會怎樣？”

上帝說“我的孩子，你去問侯捷，他寫的計算機書的讀者可能是地球上最多的”

于是他去問侯捷。

侯捷說“程式員的未來就是誘惑程式員”

這個程式員對這個未來不滿意，于是他又去問上帝。

“萬能的上帝呀，請你告訴我，我的未來會怎樣？”

上帝搖搖頭“唉，我的孩子，你還是别當程式員了”）

6、當程式員還是很有樂趣的。（當你學到新知識時，當你有新的思想見解時，當你有新的産品問世時，和知己探讨你的成果時…我問你，覺得這些是樂趣嗎？）

7、當程式員不易也不難。（世間事有難易乎？為之…；不為…。你有決心和信心嗎？）

8、你真的要當程式員？是你自己的想法？

9、你舍得花錢買書嗎？（讀好書絕對是學習程式設計的最佳捷徑。你一定會說，現在電腦書籍真T.M.D貴，沒法子，誰讓知識和技術在人家的腦袋，在人家的書裡呢；等你寫書時可以把價格定低一點，記着還有好多沒錢但想買書的兄弟很困難呀。要舍得買書，買好書，不好的的書不如不讀，其害大于其益，關于買什麼書，你可以問高手或看候捷的書評；準備一個小本子記錄你想買的書的名字，逛書店時看看，如果好就買下，記住要讀，别光買不看。） 10、我告訴你，程式就是：任何有目的的、預想好的動作序列，它是一種軟體。

11、程式設計式就是編寫程式。

12、你想好了嗎？（如果你想好了還是決定要當程式員，可以繼續往下讀；否則，你可以繼續尋找别的出路了。）

（三） 一個程式員應該具備的基礎知識和概念

1、計算機是有什麼組成的，CPU是什麼東西，其工作原理是什麼。（對于這些以及下面将要提到的概念我不會告訴你什麼答案，你可以看相應的教材，關于教材我會在下一部分詳述，記住了解最重要！）

2、機器語言和微指令集的概念。

3、程式的概念。

4、彙編語言是低級語言但不是機器語言。

5、進階語言主要有那些？（C，C＋＋，Basic，Pascal，Fortran，C#，Java等等；如果你是中國軟體業的英雄，你也寫一門語言，最好不用英語） 6、編譯程式和解釋程式的概念和其原理。（編譯器是高手和專家編寫的）

7、HTML、XML等是辨別性語言。

8、Prolog是人工智能語言。

9、作業系統OS的概念和原理。（Windows98，Windows2000，Windows NT，UNIX，Linux，等等都是OS，還有一些實時OS，嵌入OS，編這些的絕對是高手）

10、Windows程式設計說白了就是Windows API的調用。（中國的程式員很多隻是會編windows程式，用的是VB，我的建議是這些程式員頂多隻是低級編碼員，我稱其是coder）

11、VC＋＋、VB、BC、BCB、Delphi、VF等都隻是程式設計的工具和環境，不是程式設計語言。

12、面向結構的設計概念。

13、面向對象的概念。（好好了解，兄弟，這個東西還是很重要的）

14、軟體工程的概念和原理。（如果你想當老總就需要好好研究了，系統分析員比編碼員要高一個等級，薪水也高喲）

15、資料庫的概念。（要熟悉一些著名的資料庫系統和語言的名字，如Orcle，SQL，DB2，DyBase等）

16、了解網絡概念。

17、了解多媒體概念。

18、熟悉和掌握資料結構和基本算法。

19、是不是要求太高了，别着急慢慢來，進步在不知不覺之中。（一旦開始學習，一個月以後你就會有一個基本的概念；兩個月以後你就會感覺自己有了全面的基礎知識；當你知道程式設計式是怎麼回事時，說明你已經入門了。也有很多人編了很多年程式還沒有入門呢，你不會希望自己步其後塵吧。要有信心和耐心。沉不住氣怎麼能成大事？！）

（四） 教材推薦

――－推薦的教材主要還是針對概念來的，最好選用名校的教學用書。

1、《計算機組成原理》（熟悉）

2、《資料結構》（掌握）

3、《作業系統》（了解->熟悉）

4、《The C language》（掌握）

5、《編譯原理》（了解原理）

6、《彙編語言》（了解）

7、《計算機網絡》（了解）

8、《軟體工程》（了解）

9、《關系資料庫》（熟悉）

10、《The C＋＋Languege 》（掌握）

11、《面向對象設計》（掌握；結合C++學習）

（五）一些經驗和體會

1、真正的程式員用C++；（一位專家說的）

2、動手去程式設計式；

3、動腦去思考；

4、要有良好的程式設計風格；

5、讀書，讀好書，盡量讀原版書！（我反複強調這一點，讀書要有選擇，堅持讀好書，名家出的經典書，不要浪費實踐在一些粗制濫造的書上面；堅持博覽群書）

6、有自己的學習計劃；

7、總結自己的經驗教訓；（準備一個筆記本，記錄錯誤和心得）

8、不要怕學新東西；

9、要有軟體工程的思想；

10、善于發現問題，然後去尋找答案；

11、向高手請教；（要虛心直到你成為高手）

12、和同行交流；（不善于交流肯定不行）

13、懂得軟體的實質，不要被千變萬化的表象所迷惑；

14、真正要學習用的是程式設計語言和方法，不是什麼庫，什麼類，什麼工具；（學用那些什麼庫都比較簡單，但光會這些庫，我覺得還遠遠不夠）

15、學習wiodows程式設計主要是學習windows OS和win32 API；

16、有空了解一下嵌入式開發；

17、有空了解一下PDA軟體開發；

18、了解一下.NET架構和C#語言，也許它是你新的衣食父母；

19、要有耐心，不要作浮躁的人； 20、對程式加注釋，并保留你的老程式；

21、學到的東西越多，了解的越多，你就越接近專家；

22、有空去逛逛CSDN，那裡有你很多知己；

23、要有信心成為一個優秀的程式；

（六）一些好書的推薦

1、《The C Programming language》 （Keinighan & Dennis Ritchie 1988）

2、《The C++ Programming Languague》（Bjarne Stroustrup 1997）

3、《Inside The C++ Object Model》 （lippmans）

4、《Effective C++》 （同上）

5、《More Effective C++》 （同上）

6、《Exceptional c++》

7、《C++面向對象高效程式設計》

8、《設計模式》

9、《Thinking In C++》

10、《The Standard C++ Bible》（一般推薦）

11、《The Art of Computer Programming 》

12、《Programming Windows》 （Charles Petzold）

13、《VC++5.0技術内幕》

14、《MFC 深入淺出》

15、《軟體需求》

16、《Advanced Windows》

17、《C++ primer》

18、《win32程式員參考手冊》

19、《用TCP/IP進行網際互連》

20、《COM 本質論》

（七）學習計劃

――－這個學習計劃是我個人定的，也共享給大家參考一下，共同進步吧。 1、《計算機組成原理》

2、《作業系統》

3、《資料結構》

4、《彙編語言》

5、《 C 》

6、《 C++ 》

7、《VC 技術内幕》

8、《Programming Windows》

9、《深入淺出MFC》

10、《Advanced Windows》

11、《Inside The C++ Object Model》

12、《Thinking in C++》

13、《Effective C++》

14、資料庫

15、網絡

16、嵌入式OS和程式設計

17、硬體單片機

18、.NET和C#

19、軟體工程

20、UNIX和Linux

（八）後記

一年來浪費了大量的時間去摸索，去思考，走了很多的彎路，直到現在我還覺得自己是個程式設計的門外漢。我把我的一些體會和想法說出來（當然，很多都不一定正确，歡迎大家指正和讨論），也許對一些想加入程式員行列的朋友有一些建議和幫助。希望能幫助這些朋友順利走上程式設計之路，成為高手。

如果真能如此，我也就很高興了。歡迎有興趣的朋友給我發E_mail（[email protected]）；我這個人有兩大業餘愛好，其一就是讀武俠小說，其二就是結交英雄俠士。

後記：此文我用analyster的名字登入，發表在“csdn－程式人生”上了，有很多網友看了，回了，還收到幾個網友發來郵件，和我探讨，我很感謝大家對我的信任和鼓勵。

我要說明的就是我的這篇小文，主要是想給“一些想成為程式員”的朋友一些建議，幫他們尋找一條自我教育訓練的捷徑，（其實世界上沒有什麼捷徑的，我覺得一切都在于悟性，師傅領進門，修行在個人，譬如我就修行不夠）少象我一樣作大量的無用功。還有，主要就是一個程式員應該具備的基本功（個人看法）,有人稱其為“内功”，我覺得很對。沒有紮實的基本功，我們如何能夠做到遊刃有餘的編寫高品質高性能的優秀程式呢？