如何自學程式設計 How do I learing programming in C++

如何自學程式設計 How do I learing programming in C++
引用自 http://kiwi.csie.chu.edu.tw/blog/archives/83#more-83

最近為了幫助學弟們學習C++，我整理了一些東西在這
現在已經要2007了，雖然說書還是要K，不過網路可以變成一種方便補助學習
根據C++的學習路徑，而分類幾個主題來列出相關網路資源
學習程式設計

必要條件：

* 自我學習
* 記住正確的詞彙
* 善用搜尋
* 分享及討論
* 學好英文

學習程式設計大概會遵照這個流程，從12開始之後因為所有的語言都一樣，所以只要學一次。接著你就會從1～11學習各種不同的語言：

1. 資料型態(Data Type)：該語言能宣告什麼樣的變數於程式中使用？如int, float。Script語言如PHP通常只會學到純量(var),array,hash的用法。
2. 基本輸出入(Standard I/O)：如何從鍵盤讀取？如何從螢幕輸出？STDIO的觀念。
3. 流程/迴圈控制(Branch/Loop Control)：if…else/switch…case, for/while
如果有特殊的語法(syntax)也通常在此會學到
4. 函式(Function)：function要怎樣宣告？呼叫？傳遞參數？
5. 特殊用法：如C++通常會學習到指標，Template。而PHP通常會學習到HTML或Javascript
6. 函式庫(Library)：C/C++你應該學習Standard Template Library(STL)
7. 到這一階段你已經可以撰寫基本的演算法，如此你便能夠進行結構化程式設計(Structural Programming)
8. 類別(Class)：學習宣告類別並初始化物件，和物件的存取子(accessor)
9. 例外處理(Exception handling)：程式一定會出錯，可是如何去拯救？
10. 視窗程式設計：利用視窗元件重新撰寫以前的程式，並學習IDE的使用
11. 到這一階段你已經可以撰寫物件程式，如此你便能夠進行以物件為基礎的程式設計(Object-based Programming)
12. 繼承(Inheritance)：繼承的觀念，以及如何利用繼承來設計及減少你的程式碼
13. 多型(Polymorphism)：如何利用多型在多個類別/物件之間讓他們互動，也會提到一點設計樣式
14. 到這一階段你已經可以撰寫小型的應用程式，學校作業大多都沒問題，如此你便能進行物件導向程式設計(Object Oriented Programming)。到這裡你應該已經有可以打工的水準。
15. 資料庫系統(Database)：你會學習如何使用資料庫儲存你的應用程式資料
16. 軟體工程(Software Enginnering)：軟體設計的巨觀，從大的流程瞭解一套「軟體系統」是如何完成的，而程式的實做只是其一小部分。在此你會學習到UML等軟體設計中相關的文字，圖形，及術語。你也會學到傳統的Waterfall Model，有這些主題：
* 需求分析(Requirement Analysis)：如何瞭解一個軟體他究竟要完成什麼，並確實地的記錄它
* 軟體架構(Software Architecture)：在進行實做之前，先要進行設計
* 專案管理(Project Management)：一套軟體要如期完成要有很好的時程控管，也會學到利用工具來管理你的軟體狀態(SCM)。
* 軟體測試及品質：這裡你會學到利用單元測試等方法來保障你的軟體品質
17. 設計樣式(Design Pattern)：軟體設計的微觀，是前人將經常出現的軟體實做方式集合起來成為一個個「樣式」，讓你知道如何利用OOP來有規劃地撰寫你的程式。
18. 領域相關(Domain Specific)：有許多不同的領域需要不同的知識，才能撰寫出不同的程式，你想要走哪個方向？目前熱門的有，
* OpenSource(開放原碼，需要瞭解社群精神，也需要熟悉Linux,C++)
* Web(要熟悉HTML,CSS,JS…以及多種Script語言)
* Microsoft(熟悉撰寫.Net並瞭解微軟產品架構及商業模式)
* 韌體/硬體相關(熟悉C及x86組合語言)
* 學術研究/升學(通常開放原碼的領域都會接觸，Java是主流。多練習ACM題目也有幫助)
19. 至此你可以有能力開發一套完整的軟體，如果你累積了許多程式實做經驗，畢業後就可以去找該領域的軟體工程師職位了。

幾個你總是得思考的問題：

* 我在哪裡？
* 我想要往哪去？

C/C++語言核心

什麼是C/C++？

C++是Bjarne Stroustrup於1983年於貝爾實驗室發明的 ，雖然是高階語言，確有低階語言的特性，所以也有人稱作他是中階語言。(參考C++)

書籍

http://caterpillar.onlyfun.net/Gossip/CppGossip/CppGossip.html

http://squall.cs.ntou.edu.tw/cpp/index.html

http://www.books.com.tw/exep/prod/booksfile.php?item=0010178918

http://www.books.com.tw/exep/prod/booksfile.php?item=0010226566
http://www.books.com.tw/exep/prod/booksfile.php?item=0010264537

http://www.books.com.tw/exep/prod/booksfile.php?item=0010264536
參考

http://www.cplusplus.com/

http://www.cppreference.com/

http://www.msoe.edu/eecs/ce/courseinfo/stl/index.htm
物件導向程式設計(OOP)

什麼是Object Oriented Programming？

物件導向的觀念約在1960年發明，大概在1990年代成為主流。目的是以系統設計的角度或是真實情境來對應到程式設計上，幫助人去思考及撰寫。相關主題是UML。

http://www.books.com.tw/exep/prod/booksfile.php?item=0010189568

http://www.books.com.tw/exep/prod/booksfile.php?item=0010331221
視窗程式設計

目前視窗程式的作法有三種：

* 使用原生或衍生視窗函示庫撰寫。MS Windows上是Win32API, MFC。Linux上有Xlib, Qt, Gtk+。
* 使用Java或是.Net撰寫，這些是類似VM的作法(跨平台)
* 使用連結至tk的函示庫撰寫：PHP-Gtk,Perl-tk等，很多script語言都有支援(部分跨平台)

Java Swing:

http://www.oreilly.com.tw/product_java.php?id=a099

.Net(C#):

http://msdn.microsoft.com/library/cht/

Ford-Scorpio-2.0-16V-136HP-17.9kgm

Ford-Scorpio-2.0-16V-136HP-17.9kgm-　
2.0升16V車型而言，其最大馬力與最大扭力分別為136hp/6300rpm與17.9kgm/4200rpm，
引擎怠速為穩定的750rpm，斷油轉速則在 6100rpm，


還好我們家的 Scorpio 有「雪地模式」，
才能不上雪鍊也能輕鬆過關。突然間，更愛惜我們這台骨董車了！

講了這麼多，其實只是想介紹一下 Scorpio 這輛車，
這是在網路上找到的「僅存」車評文章，是從google「庫頁存檔」中挖出來的，因此沒有來源連結。

其實，當天也不確定雪地模式有沒有作用，只是知道有個按鈕有「雪鍊」的圖樣，
想說應該跟雪地有關，於是把它按下試試，才意外發現這個實用的功能。
於是回家之後便想了解一下甚麼是雪地模式。

目前以2.0/2.3升車型為主力/原廠另有2.9升性能車型

　　與舊型的Scorpio車系相同，新型Scorpio亦有2.0升及2.9升兩種設定，
隨著改型而來的新款引擎也較舊引擎來得更為先進，以 2.0升引擎為例，舊引擎為8氣門設定，輸出為115hp與17.3kgm，
新引擎則為16氣門設定，輸出則上升為136hp與17.9kgm，
2.9升的6缸引擎的引擎輸出更從舊有的145hp上升到207hp，
當然啦﹗氣門數也從12變為24，以本文所試駕的Scorpio　
2.0升16V車型而言，其最大馬力與最大扭力分別為136hp/6300rpm與17.9kgm/4200rpm，
引擎怠速為穩定的750rpm，斷油轉速則在 6100rpm，

以平均水準來看，這具引擎在噪音及振動的控制較舊款引擎精良許多，
在良好的車室隔音之下，引擎的運轉尚稱平順，引擎的精致度被刻意的加強，
據了解，在Ford　New　Scorpio上所使用的2.0升16氣門引擎，與Mondeo　2.0所使用的引擎款式為相同的設定，
不過 Mondeo將這具引擎設計為橫式排列，而Scorpio則將這具引擎「直」的擺放在引擎室內，為何會有這種差異，
因為Scorpio為後輪傳動設計（注 ︰目前在德製的中、大型房車上仍採用後輪傳動的車輛並不多，
BMW新五系列、M-Benz新E-Class、及Ford　New　Scorpio皆為前置引擎後輪傳動設計），
嚴格上來說，以136hp與17.9kgm的動力輸出來推展重達1450kg的諾大車身，可想而知的，
動力性能並不是Ford　New　Scorpio所擅長的地方。
但Scorpio這具引擎卻使用了可變進氣系統（原廠稱為︰VI　System），
從技術資料顯示，藉由這套系統可以改善低速時的扭力回應。

三模式四速變速箱/日常使用綽綽有余

　　Ford　Scorpio所使用的電子式四前速自動變箱為GM所研發之系統，
它具有三種模式可供選擇，分別為雪地、經濟與跑車模式，
在雪地模式中、變速箱將以二檔起步，以防止胎環因輸出的扭力過大而打滑，
其餘的經濟與跑車模式，我想也不用再多加解釋，也由於馬力重量比的緣故，起步加速並非 Scorpio所專長，
但隨著油門開啟幅度的大小，變速箱非常稱職地將動力完整地分發到每一個檔位之中，在每一個檔位的銜接上，
筆者刻意地觀察其換檔振動，經過來回的反覆試車，這具變速箱對於換檔震動的抑制相當成功，
在每一個換檔過程中，變速箱電腦會將換檔信號告知引擎監理系統，
同時，引擎的點火正時在變速箱換檔時將被瞬間落後，此舉的最大目的在於減少換檔時所造成的振動，
當然啦，油壓設計的引擎支柱及新設計的扭力轉換器都居功不少，
以本地對於自排的需求來看，Ford　Scorpio的變速箱確實綽綽有余﹗

對抗坑洞能力一流/轉向特性略帶過度

　　Ford　New　Scorpio的前懸吊為麥弗遜式支柱，後則為多連杆架構，
在軸距近2800mm的余威之下，Ford　New　 Scorpio擁有極為優異的乘坐舒適性及高速穩定柱，
整體的懸吊設定為典型的舒適取向，話雖如此，New　Scorpio的底盤卻擁有極為優異的韌性，
減震筒總能在最短的時間內，抓住彈簧所產生的彈跳，
在優良的底盤隔音之下，Ford　Scorpio擁有絕佳的避震能力，不知道這種特質是否為許多德系中、大型房車所共同擁有，
Ford　New　Scorpio處理坑洞的能力若與奔馳新E-Class相較，兩者絕對可以相提並論，
在操控性與轉向特質上， Ford　New　Scorpio是一輛標準的「舒適車」，
她絕對不適合山區彎道中的劇烈操駕，雖然Ford　New　Scorpio因為後驅帶來些許的轉向過度，
但在車行速度控制良好的前提之下，轉向過度並不容易出現，
簡而言之，Ford　New　Scorpio的底盤穩定而安全，這點讀者不可不知。

車室空間極為寬廣/組裝品性頗為精良

　　若說起Ford　New　Scorpio的乘坐空間，那可就值得大書特書了，
在良好的車室設計概念及長軸距的雙重輔助之下，Ford　 Scorpio的車室空間，堪稱空前絕後，簡單的說就是夠寬的啦﹗
前後座如果同時塞下壯碩男子，車室空間依舊寬裕，在組裝品性上，Ford　New　 Scorpio仍然保有日耳曼民族應有的組裝水準，
在深色系的內裝色調處理下，仿桃木紋飾的出現，為冷調的日耳曼風格帶來些許暖意，
各式零組件的嵌裝與間隙控制均相當精良，在良好隔音及避震的雙重防護之下，
Ford　New　Scorpio並沒有明顯的車身及內裝異音，這也是它的另一個值得稱揚之處。

試車短評

　　車壇發展至今，同質化的問題一直困擾各大車廠的車身外型設計師，
各車廠的設計師無不絞盡腦汁努力地將流線與車廠道統合而為一，並試圖表現下旗下每一款新車之上，但成功的又有多少？
　　一部78年份的Alfa　GTV為何至今仍為車迷內所津津樂道，
其緣由在此，光看Ford　New　Scorpio的外型，就可以讓人足足站立三分鐘，因為Ford大膽地將「概念車」的理念使用在量產車之上，
Ford　New　Scorpio讓人印象深刻的程度絕對遠超過一般日系車種，這絕對是無庸置疑的。
　　Ford　New　Scorpio的齊全配備（雙Airbag、ABS、紅外線防盜…），與超人一等的乘坐空間足以彌補略顯不足的動力性能，
氣派的尺碼與先進的型式與其他歐系同級車相較亦不遑多讓，
對於一部德製的後驅的大型房車而言，價格將是另一個影響消費的原素，
如果你（你）是一個理性的消費者，Ford　New　Scorpio將是一款不錯購車選擇。

汽車定期保養項目圖表

汽車定期保養項目圖表

持續讓程式碼保持進步的能力

程式碼的演化之路(1)持續讓程式碼保持進步的能力 http://www.ithome.com.tw/itadm/article.php?c=48746

從預先做的設計準備及未來成本，選出最佳平衡，因為最適合未來的，不一定最適合當下。隨著環境動態地演化，才能保持在最佳狀態。

需求的擴充及變化，幾乎是軟體開發中不變的現象。面對這樣的狀況，設計者若是嘗試著預見未來，提前做好相關的因應措施，一次便將滿足需求的設計到位，便很容易落入過度工程化（over-engineering）的陷阱當中。 試著一次到位的心態，是產生了問題，然而，面對許多設計者所不願處理的需求擴充及變化，我們還曾經給過以下的建議：「讓你的軟體架構，具有好的體質，足以 快速的反應。具有彈性，又不會過度擴張彈性。」，「初期只有基礎的彈性，每次變化後，都再加強一個等級的彈性，使得它足以通過下一次變化的考驗。」，其 實，這樣的建議想表達的，便是讓你的程式碼持續保持演化的能力。 真實世界中的生物，必須面對環境的變遷，進而持續演化。但是，沒有任何一種生物，能夠預知千萬年後世界的風貌，使得自己在最初的時候，就變成最適合未來的長相。因為，最適合未來的，不意謂著最適合當下。一直隨著環境動態地演化，才能保持在最適合當下的狀態。 最初的設計需適當地加以預估 程式碼所面對的需求變更，就好像生物所面對的環境的變化，只有持續演化，才能讓程式碼不斷保持在最合適的狀態。因此接下來，我想試著探討程式碼的演化之路。 程式碼的變化，基本上有幾大類：一、擴充；二、變異；三、萎縮。 擴充指的是為系統擴充新的功能，使得它具備更多的能力。變異指的則是修改系統現有功能的行為，使得它改變固有能力的展現方式。萎縮，指的則是將系統現有的功能予以廢棄，之後不再使用，這形同削減了系統的既有能力。 當我們遭遇到上述的三種變化時，我們應當如何因應呢？ 在談如何因應這三種變化前，我們應當先來談談「如何做出最初版的設計」。最初版的設計，無疑地，必須符合最初的需求。 設計必須滿足需求，這是最基本的。但我們的設計還必須提供更多的可能性。許多設計者會在最初版的設計就遭遇到困難，因為他們的腦海裡，一心只想要 解決眼前的問題，也就是滿足自己所看到的這一份需求規格。運氣好的時候，需求不動如山，「能捉老鼠的就是好貓」，可以滿足需求的，就是好設計。但是，很少 會有這種運氣──不論專案或產品的開發，需求的變更，皆屬兵家常事，所以在做最初版的設計時，就必須先預測需求下一步會往哪裡變化。例如，在開發一個電子 商務網站時，雖然最初的需求規格，僅提到要連接某一個付款的閘道（payment gateway）。但是，從對專案的背景及氣氛，甚至是客戶的預告，有時可以嗅出未來必須支援其他付款閘道的可能性。 一名好的設計者，在做最初的設計時，雖然只會實作連接單一付款閘道的機制，但是，他會在設計中暗自埋下伏筆──預留擴充的空間。使得他日一旦連接其他付款閘道的新需求正式納入規格時，就可以輕易地加上另一臺付款閘道的連接機制，卻同時又對現有程式碼的影響很小。 如何辦到上述的設計呢？舉例來說，當你已經預知付款閘道，可能要同時支援多臺而不只是單臺時，你可以選擇用一個介面來表示付款閘道的功能，而以一 類別實作立即必須支援的付款閘道介面。假如要用這臺付款閘道，你可以有很多選擇，最簡單的方式是直接產生該類別的實例，但將它轉型成為介面後再使用。好 比： PaymentGateway pg = （PaymentGateway） new PaymentGatewayImpl1（）; 你也可以考慮在此時，便引入一個Simple Factory Method的設計模式，直接讓程式碼與PaymentGatewayImpl1完全無關。 PaymentGateway pg = PaymentGatewayFactory.create（）; 倘若採取第一種寫法︰當確定要加入第二個付款閘道的機制時，程式碼的變動就會比較多。因為你得逐一找出程式碼中，所有利用new去產生 PaymentGatewayImpl1的地方，然後改以泛工廠族系的設計模式，來產生具體的付款閘道實作。不過，有個優點是，所有使用 PaymentGateway介面的程式碼都不會影響到，而這正是先前在「類別物件的生成」一文中所提到的。 倘若採取第二種寫法︰確定要加入第二個付款閘道的機制時，程式碼的變動較少。因為只需要擴充PaymentGatewayFactory的內容，其餘程式碼毋需變動，變動的幅度因而更小了。 從已知的情境去推估，謹慎控制準備的規模 從這個例子，你可以觀察出來幾個要領。 首先，雖然要避免過度工程化，卻意謂著我們還是得預測未來，但並非全面的想像。我們在演化程式碼時，儘管不要求要精確的認知未來，卻需要試著從大 方向上去察覺趨勢。我們不確定會加入什麼付款閘道，甚至難以確定究竟客戶會不會真的想加入，所以，我們提前做了一些準備，可是這準備又沒有做足。 不立即做，是因為不想將力氣浪費在也許不可能發生的事情上，但我們仍舊要做一些準備，是因為必須考慮到這事會發生的可能性。 好比上例中的設計，我們沒有真的實作出所有的付款閘道機制，在第一種設計中，我們甚至連Simple Factory Method都省去了（雖然省去Simple Factory Method節省不了多少力氣，不過在此例中是為了突顯預先做準備，還是會產生投入程度的差異）。但是，這樣的準備，就足以讓我們確定一件事──要支援其 他付款閘道時，對自身的程式碼衝擊應該控制到最低的程度。這便是我所謂的「為下一次的變化做準備」。我們並不是直接就變成那樣，但是妥善地準備，盡可能將 節省額外再投入的力氣。 準備多寡與花在變更的力氣大小成反比 上例中，我們同樣是試著為下一次的變化做準備，方式卻有兩種不同等級的差異。有時，我們會選擇花較少的力氣、準備少一點，等到需求確實發生時，在變更上再多花一點力氣。有時，我們會選擇花比較多的力氣，多做準備，這麼一來，倘若需求確實發生時，花在變更的力氣就會少一些。 事實上，這中間或許存在多個不同的層次，如何選擇呢？這端視設計者對需求發生可能機率的評估。倘若設計者認為機率偏高，那麼就可以考慮多做準備。 反之，準備少一點也無妨。因為機率多半沒有任何量化的標準，設計者不妨選擇C/P比最高的準備方式，選擇初期投資（預先做的設計準備）以及未來成本（需求 變化造成的衝擊）的最佳平衡。或許這是一場設計者在開發過程中的賭局吧！ 在每一階段，設計者都應該試著替下一個階段作打算，儲備變化的能量，盡量讓一個階段與下一個階段之間保持小幅度的調整，記住！不要一次引入過於巨大的變化，讓程式碼往正確的方向演化，做法上將更靈活，不必多走冤枉路。 作者簡介： 王建興 清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。