在如下領域,C++有着根本性的優點:低級系統程序設計、高級系統程序設計、嵌入式程序設計、數值科學計算、通用程序設計以及混合系統設計等等。讓咱們略微展開描述一下:c++
1. 低級系統程序設計:C++是迄今爲止最好的低級程序設計語言。程序員
2. 高級系統程序設計:包括操做系統核心、網絡管理系統、編譯系統、電子郵件系統、文字排版系統、圖像和聲音的編排系統、通信系統、用戶界面、數據庫系統等等。數據庫
3. 嵌入式系統:包括照相機、汽車、火箭、電話交換機、汽車等等。編程
4. 數值/科學計算:包括仿真、實時數據獲取和數據庫訪問等等。設計模式
Bjarne的我的主頁上,有一頁applications,那兒列出了一些(所有或大部分)使用C++編寫的系統、應用程序和庫。下面是一些例子:網絡
1. Adobe Systems:全部主要應用程序都使用C++開發而成,好比Photoshop & ImageReady、Illustrator和Acrobat等。數據結構
2. Maya:知道「蜘蛛人」、「指環王」的電腦特技是使用什麼軟件作出來的嗎?沒錯,就是Maya。架構
3. Amazon.com:使用C++開發大型電子商務軟件。app
4. Apple:部分重要「零件」採用C++編寫而成。編程語言
5. AT&T:美國最大的電訊技術提供商,主要產品採用C++開發。
6. Google:Web搜索引擎採用C++編寫。
7. IBM:OS/400。
8. Microsoft:如下產品主要採用C++(Visual C++)編寫:
9. KDE:K Desktop Environment(Linux)。
10. Symbian OS:最流行的蜂窩電話OS之一。
我一般使用C++進行高端程序開發。
「一般」一詞沒什麼好說的,有時只是出於公司文化或我的愛好方面的緣由,選用了別的語言而不是C++,或者相反。我所說的「高端」是指:關鍵業務處理,效率要求極高,實時性要求高等等。
我看見幾乎全部嚴肅的工控系統軟件和實時數據採集、處理和表現(主要是圖形)軟件,都是採用C++(或C,少部分採用Java)編寫而成的。
據個人瞭解,我原先所在的研究院幾乎每個研究所都在不一樣程度地使用C++(以及一些別的語言)。
想一想看,迄今爲止,現代Unix操做系統的各類變體上,最常使用的是什麼樣的開發語言?(C/C++)
C++語言
C++語言是靈活,但首先要看看使用者能不能發揮它的靈活性;C++語言夠強大,但要看看使用者有沒有本事發揮它的強大功能。
使用C++語言和編譯器編寫一個快速的程序,並不難,不過編寫一個強健而高效的大型程序,就不是那麼容易了。
語言之間的區別,絕非只是大括號和begin、end或Sub、End Sub之間的區別。選擇了一種語言,你就選擇了一種思惟方式,一種程序設計思想。要想跳出語言的束縛,首先要對語言有着深入的認識和透徹的把握。世界上一些大師級的人物,也經常絕不掩飾本身對某種語言(我並無專指C++)的偏心。一些人對語言尚只知其一;不知其二,就大談要跳出語言的束縛了 — 你無需跳出,由於你根本未曾深刻。
純粹的技術性(學術性)研究,總能給人帶來純粹的快樂。C++語言複雜至極,可研究性極強,但通常來講,沒有3~5年的持續學習、思考、使用,是不可能真正掌握C++的。
我不是惟語言論或惟工具論者,但我反對抹殺不一樣語言、不一樣開發工具之間的區別。抱持這種觀點的人,若非無知,便是別有用心。這就比如雜牌筆記本電腦廠商最喜歡叫嚷「筆記本電腦已經進入同質時代」同樣,雜牌機怎麼能和IBM相比?
選擇C++或選擇Java,要看你我的愛好和對未來的打算。雖然只是語言上的差異,但由此決定的就業領域的確不同。
無論你走什麼樣的技術路線,無論你用不用它作開發,學習C++總會帶來長遠的好處。一名熟悉C++的開發人員,假如他不是一個偏執狂的話,再學習Java或C#,都要容易得多。
C++不過是一門編程語言,咱們老是要用它來解決實際問題,因此要學習開發工具(好比Visual C++),瞭解操做系統(好比API),熟悉領域知識(好比電力系統),掌握其餘軟件技術(好比數據庫),等等。編寫真正的代碼,解決實際問題的能力,纔是衡量一名程序員是否有真水平的惟一標準。
設計模式和統一建模語言
設計模式(Design Patterns)和統一建模語言(Unified Modeling Language,UML)是兩個不一樣的概念。前者主要目標在於提供可重用的面向對象軟件設計方案,後者則是一種描繪軟件藍圖的標準語言。
固然了,可使用UML來描述設計模式的結構。
UML所描述的模型能夠映射成C++、C#、Java等語言代碼,甚至能夠映射到關係型數據庫。映射過程能夠是雙向的,通常都有相應的軟件工具(或插件)支持。
不一樣的語言,特性有所差異,這多少會影響設計模式在該語言中的實現(方式、難易)。比方說,假如使用C語言來描述設計模式,那麼,繼承、封裝和多態等特性就變成了須要研究的設計模式,但在任何一門面向對象的語言中,這都純屬多餘。
如今市面上尚未看到象樣的以C#爲手段講述設計模式的書(我沒有看到),但這並不打緊,假若有興趣,徹底能夠讀一讀《Design Patterns: Elements of Reusable Object-Oriented Software》(中文版名《設計模式》機械工業出版社)這本書,儘管它主要以C++和Smalltalk語言爲講解手段。
設計模式自己無所謂好壞,根據你要解決的目標問題,選擇適當的設計模式。
系統架構
在企業級軟件開發中,架構第一重要。架構有缺陷,系統就存在硬傷。優秀的架構來自於優秀的設計。這一點毋庸置疑。
任何成功的軟件,即便它沒有明確地使用建模思想、架構方法,但在骨子裏、潛意識中,大都具備良好的設計思想和架構。
只有寫過好多好多代碼之後,只有作過一些夠分量的企業級項目以後,纔可能對軟件架構造成清晰的認識。很難想像一個連幾行像樣的代碼都沒有寫過的人,對程序思想和架構卻有着深入的認識。這種人,十有八九屬於紙上談兵之輩。
咱們時不時會看到這種狀況,軟件的設計也不算太差,但程序員要麼不知道怎麼寫實現代碼,要麼是代碼寫得缺少效率,或不夠強健,甚至有時連「架構師」本身對此都束手無策。
咱們也經常聽到一些聲音,不要太拘泥於語言(技術)細節了,要從大處着眼,要有大局觀,架構怎麼怎麼重要,這些都是大實話。不過現實狀況每每是,不少程序員不是太拘泥於語言(技術)細節了,而是對語言(技術)細節掌握得還遠遠不夠。
書本知識的重要性毋庸置疑,但毫不要覺得讀了兩本書,本身就成了牛氣的架構師、設計師或者什麼建模專家。
從前的軟件開發埋頭實踐而缺少必要的理論指導。如今愈來愈走向另一個極端:設計文稿愈來愈圖文並茂,琳琅滿目,但開發出來的軟件卻比之前差不少。這種表面文章,意義何在?
數據庫
大多數軟件都要和數據庫打交道,並不是只有MIS類軟件如此,數據庫知識幾乎是非掌握不可的,無非使用深度和廣度有別而已。迄今爲止,我編寫的每個項目軟件,都要訪問數據庫,有一個程序甚至同時要跟兩個數據庫打交道(Oracle和SQL Server)。
若是你上過任何一門數據庫基礎理論方面的課,或認真看過任何一本數據庫基礎理論方面的書,或許都沒必要再買更多的(相似的)書。二十多年以來,關係式數據庫理論之穩定,遠遠超過C++語言的穩定。