C/C++程式員何去何從

         滾滾長江東逝水，浪花淘盡英雄。雖說是個人英雄的時代已經成為過去，但我們仍然不能對這樣的榜樣們有所忘懷，他們是WPS求伯君、CCDOS嚴援朝、2.13吳曉軍、四通利方王志東、CCED朱崇君、UCDOS鮑嶽橋等。因為他們不僅是成名的優秀程式員，也不僅是在寫文章時所必須想到的人物，更主要的是他們激蕩了很多批程式員的編程熱情，堅定了學會彙編和C就能走天下的決心和勇氣，他們代表著以往中國軟體業的輝煌。

         多年來，我們一直就這樣追隨著，也不曾懷疑過有什麼不對的地方。即使在DOS已成為過去，Windows和Internet獨霸天下的今天，我們也不曾懷疑過。

         我們能懷疑嗎？我們眼見的執行個體太多了。我們不是看到Linux等作業系統和許多應用程式的核心都是用C來編製的嗎？即使在高校的電腦或非電腦專業中，C/C++程式設計課程的廣泛開設不也是一個極好的證明嗎？NortonUtility首席設計師EnriqueSalem不是也認為"每個人都應當使用C++"嗎？
難道還有什麼懷疑嗎？

         誠然，我們不能否認C/C++語言的超凡魅力。然而我們不禁要設問，在Windows流行的今天，用WindowsC編製出介面獨特、功能強大的應用程式，你能嗎？即使能，你需要多少時間？

         在有許多程式開發工具可供選擇的今天，強調"C/C++是程式程式員所必須掌握的語言"難道就沒有人真的敢站出來提出質疑嗎？
其實，在網路一統天下的今天，任何應用程式都必須經過網路的驗證。誰的軟體好用，誰就會被認可。為了能達到這樣的目標，許多Windows程式員都選擇了簡單易學、能快速有效地開發的VisualBasic、Dephi等工具。E_book電子書閱讀程式就是其中一例，它是李曉東用VB設計的。

         如果這顯得太過蒼白無力的話，那麼讓我們先來看看C語言從過去到現在的發展曆程，看看它為什麼這麼發展。
眾所周知，C語言是在70年代發展的語言，由於當時人們設想一種集低級語言和進階語言優點於一身的語言，於是C語言就誕生。基於它的簡結、緊湊、方便和靈活，它很快就成為國際上廣泛流行的語言。

         然而，C語言終究是面向過程的語言，資料和處理資料的程式是分離的。當對某段程式進行了修改或刪除時，整個程式中所有與其相關的部分都要進行相應的修改，從而程式碼的維護比較困難。為了避免這種情況的發生，在C的基礎上中引用了物件導向的設計方法。它是將資料及處理資料的相應函數"封裝"到一個類中，而使用類資料變數則稱為對象。在一個對象內，只有屬於該對象的函數才可以存取該對象的資料。這樣，其他函數就不會無意中破壞它的內容，從而達到保護和隱藏資料的效果。這就是C++。當然，物件導向的C++還支援多重繼承、模板、操作符重載、內嵌函式定義、預先處理、宏、全域靜態類變數、嵌套類定義等等。

         C++太複雜了，任何一個使用C++開發人員的企業必將付出更多的成本，因為優秀的C++程式員是少而又少。基於軟體企業化的需要，人們很自然地需要一種簡單易用、物件導向、安全靈活的"新一代Windows服務"(NextGenerationWindowsServices，簡寫為NGWS)應用程式的語言，於是C#出現了。它全方位簡化了C++的功能，使其具有C++所沒有的簡單易學的優勢。它既沒有C++"悲劇性"的指標概念，也沒有類似"：："、"."和"->"的"愚蠢"操作。

         因此我們也可以說，C#才是程式員們所必須掌握的語言。但是，我們不能忽視這一點，語言總歸是程式員的工具，誰具有簡單易用、支援最新技術並能快速有效地進行軟體開發，誰就是程式員的工具。

         如果上述的結論還不能接受的話，那麼讓我們看看現在C++程式員的窘境吧！

         就目前而言，選擇C++就意味著選擇VisualC++，而不C++Builder。這是C++程式員第一件讓人頭痛的事。因為VC與Windows98/NT同出一爐，相同功能的VisualC++應用程式編譯後，其大小要比C++Builder小得多。不僅如此，其穩定性和完善程式要比C++Builder要強得多。

         但是"VisualC++"這個名字曾誤導了很多人，他們認為自己買了一套完全可視的編程系統，類似於VisualBasic，並在剛開始的幾天總這樣幻想。然而不久，人們認識到他們必須實際編寫和閱讀C++代碼。雖然VisualC++嚮導可以節約時間和提高正確性，但程式員必須理解嚮導所產生的代碼，最主要的，還必須理解MicrosoftFoundationClass(MFC)Library的結構和Windows作業系統的內部工作方式。許多C/C++的DOS平台的程式員把這種工作方式評價為"枯燥且艱深晦澀"的過程。儘管新版本的VisualC++6.0提供了控制台應用程式類型，使DOS程式員能方便地進入MFC應用程式的開發，但仍然不能從根本上改變上述弊端。

         選擇了VisualC++，就必然選擇MFC，一種程式結構，一種編程風格。但由於MFC是OWL同時代的產物，已經落後於VCL一個時代了。從開發出基於ATL的WTL可以反襯出MFC的不足。這恐怕是VisualC++程式員最窘的地方。

         但我們暫且不提MFC過時的尷尬，單是稍稍地改變一下應用程式的外觀，VisualC++已是力不從心了。例如，想要改變控制項的字型和背景，你得重建一個類，而VB只需更改一下屬性。從VisualC++介面設計的網站的火爆可見一斑。

         不僅如此，VisualC++程式員也時常感到另外一種尷尬，一個小小的BMP、JPG圖片顯示，在VisualBasic中輕而易舉事件，到了VC居然需要那麼多的代碼，而且在資料庫應用程式的開發中還常發生許多一些細微的錯誤，令程式員們大為惱火。更為甚者，如果有人還想用VisualC++編寫Internet/Intranet程式的話，那簡直就是自尋煩惱。

         雖然，一個優秀VisualC++程式的薪水要比其他程式員高。但是，他所花費的精力不是其他程式員能比擬的，他不僅需要承擔高昂的培訓費，而且還要承擔90%不成功的機率。這恐怕是想成為VisualC++程式員的人最苦惱的事。

         當然，我們不是勸你放棄使用C/C++語言，相反還十分支援。因為使用C/C++編寫的程式結構和演算法能被更多人接受，畢竟C影響了整整20個年頭。但是時過今天，我們還能靠它來"謀生"嗎？

         相信你已經有了自己的答案。當然，我們之所以跳出來，是希望程式員們不單是在這個方面去思考，更主要的是：在我們國家軟體發展浪潮到來的今天，我們不能再盲從，我們應該關注軟體產業、關注互連網產業、關注資訊產業。我們也應該有自己的歸宿，難道印度軟體大國給我們的啟示還不夠多嗎？

========================================
暈！印度?軟體大國不錯，但不是軟體強國。其性質跟大連軟體園如出一轍。
1.高昂的培訓費？呵呵，俺是自學的，O學費，只是花點錢買了些書罷了。
2.承擔90%不成功的機率?正所謂別人不敢做的我敢做，別人做不了的我能做。即使99%不成功，俺也要拼一把。不入虎穴，焉得虎子。
3.所花費的精力不是其他程式員能比擬的?俺熱情似火，精力充沛，俺變態俺怕誰。
4.一個優秀VisualC++程式的薪水要比其他程式員高。總算說了句人話!!-_-!!
只要Microsoft沒有放棄C++，只要StarCraft、WarCraft、3DStudioMAX、PhotoShop、NeedForSpeed還是用C++開發的，俺就不放棄C++。除非Microsoft裡面沒有一個人再使用C++，除非Microsoft裡面的所有人都使用C#.NET，俺就要將C++進行到底！如果Microsoft裡面的所有人都用C#.NET，俺利馬轉行C#.NET。