C++學習經驗談
有人認為後期的C++趨向學院派風格,走進了一味追求技術和難度的誤區,
逐漸脫離主流的Programmers.
有人認為C++由於複雜度導致在現代軟體工程中的地盤不斷縮水.
也有人認為,C++無任對特定領域應用還是研究來說,都足夠的優秀.
一、面對Object-Pascal、Java、C#等語言,還需要C++ ?
首先,就方法學來說,不可否認,OO方法學本身具有構造的系統隨著工程的進行複雜
度膨脹速度驚人.而且,對於上點規模的工程,為了構建OO系統,在OOA、OOD階段,設計
者需要極高的水準.而以OOP為一典範亦作為OOP代表的C++在文法語義的設計上明顯採用為了功能而不惜增加設計複雜度的策略.然而這一切的複雜,自然帶來了好處,包括系統的可擴充性、可重用性等.這裡好象存在一層很微妙的關係,上規模的系統為了可擴充性、可重用性等優點選擇OO方法學,然而在OOA、OOD階段就需要極大的投入(也許在00方法學中,A和D在軟體工程中的地位體現的更明顯吧~).
這個世界關於語言之間的討論可能時刻進行著,個人一直認為:
1.首先每種語言有自己的適用領域,就應用而言,沒有必要將語言勉強的拿到一起比較.
構建公司資訊系統,自然會選擇Java、dotNET或其它的方案(事實上,這種系統一般應
該多種語言協同開發,以獲得組件效能最佳).可能多種語言同適合某個項目,那麼具體就自己裁決了.譬如做一個資訊管理系統,選擇C++環境的絕對很少,PB或Delphi、VB都是不錯的選擇.在初學習階段"因愛而選(更多的具有偶然性或者與身處環境有關)"、對於開發人員基本是"因用而選".在成熟後,"因用而學"我感覺是根本也是最實際的指導原則.
2.關於語言複雜度的問題:語言是工具,是不需要也不能太複雜的.我一直支援語言應該朝專業化(這裡指標對義務和特定應用場合)和簡單化方向發展.這才是語言的本質之所在.業務是軟體實施的根本.對於軟體開發著來說很多情況下,業務是最難搞定的,或者說,用軟體來真實細緻安全的類比業務是很困難的.前幾天,學籍管理科的老師還跟我說,他們的一個學籍管理軟體讓兩個研究生不斷的完善,三年才算[完全符合他的業務要求].如果你只是耳聞某某語言何等的複雜、難學而學之,那麼可能你錯了~就個人而言,為了技術而技術是不可取的:)
3.然而這個世界是現實的,不如你想象的那樣.並不是所有領域都有簡單、強大、貼近業務 的語言.在這個層次上說,對於獻身企業級資訊應用系統開發人員,Java、C#、Object-Pascal等的確是福音~~然而在系統軟體和其它對效能、控製程度要求較高的如
工控系統、高效能運算,即時系統,軍用軟體等領域可就缺不了C++(C)(不過這些領域 明顯的專業知識占絕對部分的重量).可見,緊從語言上說,C++(C)依然佔據著一片天地. 嚴格來講,C是作為C++的一競爭者出現的(不管這些了:)).
二、C++是否真的走進了追求技術的誤區
自從,GP思想在C++上的第一個作品STL正式納入標準庫,關於C++走進技術誤區的流言便沒有停止過,Boost、作為GP領軍人物之一的Andrei Alexandrescu提倡並實踐著(Loki)的編譯時間編程、將設計模式思想引入庫設計,使得流言快被提上議程討論了:).
然而,GP真的只是技術嗎?我一直認為,就OO來說,本人曾經作過這樣的思考:
-----------------------------------------------------------------------------
真正的對象應該至少能夠具有:自主的適應環境(維護足夠的"意識")
1.自發行為的意識更強
2.反應能力更強
3.對外有足夠的獨立性
現在的OO,更像是建立在PO上的,不過是對象代替了函數.
但事實上,無論對象能力多高,過程表現絕對少不了.
Agent :我想是表達和反應能力最強的.
COM : 比Object-Based手法構造出的對象表達、反應、適應能力高很多.
不過There is no magic.還不過是一般的技巧構造出來的,看透了什麼都沒有了:)
GP :不能將它看作無謂的技術追求,[從我們談論的這個節點看來,它的實質我認為[至
少]是]:提高了構造的對象的適應能力(不是自發行為能力)的一種手段.
Andrei Alexandrescu的《Generic Programming :類型的else-if-then機制》
這篇文章可作為一精彩的證明.
-----------------------------------------------------------------------------
三、C++怎麼學?
首先聲明:本人對之也只能說略之一二(C++太博大了:))
孟岩先生曾經提過"C++需要自由的心",我要說"C++需要自由的心和手",我敢肯定我想的自由和孟岩先生的自由是不同的.
因為我的自由就個人詮釋是 :"用自己的思路來自由的寫驗證性的usecase"
就個人的學習心得而言 :
1.在你學習C++的過程中,你首先需要紮實的實踐一本C++基礎教程,這個教程不在深而在全.使你能夠全覽之.最好結合基本資料結構來練習.不要整天Hello World~~Hello MM的.
2.再下來你需要《(More)Effective C++》,它使你可以對C++也多了份思考,也瞭解到一些技巧和誤區,不過,你需要同步實踐,不然可能一時你並不能真正掌握這些技巧、避開誤區.
3.提高,你需要:(下面的書可能已經講爛了:))
《Design Pattern》 :個人感覺,設計模式雖說是一種思維方式,具體實現上,只是
對OOP語言的發掘和巧妙組合而已.而且這裡組合是主要的,
特性是有限的,這本書中有幾個模式沒用虛特性的?
C++ Standard Document: 在你用它來做專項研究的時候,就會體會到什麼才叫真正的
全而深 (自然指在文法和語義的闡述上).
《STL源碼剖析》 :沒有深厚的功底,想來個閉門造車獨挑STL源碼是不可能的.
不過,這本說也重在關鍵技術的講解和引導罷了~~
這裡關於GP和STL的名著不少,本人沒看過。不做品評。
《 Inside The C++ Object Model》:最具價值的一本書,沒了它,C++永遠是個迷,哪怕
你浸淫之N載~~
《Moden In C++ Design》 :這裡的很多思路是你自己的思維很難接觸到的~~:)
我不得不佩服Andrei Alexandrescu.
市面上其它的C++書籍可牛車載,我感覺除了《The Design And Evolution Of C++》是異品,值得一讀.其它的不建議花太多的時間,哪怕是Bjarne Stroustrup、Stanley B.Lippman等的作品.自然,你有時間讀更好,反正我現在有點後悔,當初只顧多,不顧深讀,反覆讀.經典的書不在本數多,在於每本讀的遍數多.一經驗之談,BBS上經常有人,在介紹COM技術書籍時,想也不想的指出,入門級<<Inside The COM>>.是這樣的嗎?我想,正如Dale Rogerson所說,將這本書完全看懂,你就是COM專家了~~書中,作者很多話可能你沒有注意到,因為你還不懂之,對之沒感覺,一遍翻下來,感覺 哦~~簡單~全看了 這些書,跟國內的很多書籍最大的不同就是
國內書籍的作者寫的出,可能自己還不懂:)Copy什麼資料上的:)??
4.浸淫一門語言本身的文法語義再久,你不一定能夠深入它的精妙之處.
你需要學習應用這門語言的實作品(技術),你可以研究一些FrameWork或是一些具體的技術 如CORBA、COM等.就個人而已,有心接觸C++十個月左右,對於Virtual的認識有過幾次較大的的改變.在《 Inside The C++ Object Model》中算第一次,在《COM本質論》中關於COM對二進位相容布局需求而用虛機制來解決是第二次,到目前為止,使我對virtual流下最深刻印象的是在Automation技術中組件由於環境是否有能力分析virtual結構而導致是否需要分發介面的問題.如果,整天抱著《C++文法語義深入》這樣的書,我不知你何時才能真正瞭解C++很多的特性.
即使你可以對別人說上一大套,這行啊~那不行啊~~云云~~:)
在這整個的過程中,我喜歡這樣對學弟說,你需要經常將C++的各種特性在腦中反覆混合醞踉,這也是我強調學基礎時,要求教材知識點全的原因.經常的,為了研究某些特性而自由的寫、修改、增加UseCase,是我自認為很好的一個習慣.整天記他人的經驗之言,不知幾個月後還記得幾層:)?
也許上面的敘述是概括了些:)?
總之,我認為學習C++,需要多思考(譬如你想想為什麼模板類繼承不支援virtual、模板
類繼承,基類執行個體和繼承類執行個體產生的關係是什麼樣的)、
多寫usecase、
多將一堆特性混合醞晾(譬如模板類
成員簽名、多種嵌套模板類成員簽名、嵌套類與包裹類生命期
控制等等)
要儘早選擇應用方向(這點很重要,附加個人觀點:大多數人認為理論很
難,可是我要說:應用一樣是有難度的:)).
將00工程學中的理論適時的來對照自己的行為.
後話:
上面提到,就應用而已,比較語言的是沒有什麼意義的.然而我想說的是,不敢想象
沒有經過C++錘鍊的人,可以深入的研究C#(事實上,我一直也不人為C#比C++好學,只是他們的深入點是不同的,冒昧說一句,C++中很多難度是人為製造出來的),就目前的情況來說,還有就是由於C++曆史、
社團、資源等因素.
共勉 :
因用而擇、因愛而擇
學究其深
勿以善小而不為