Visual C++應用程序編譯技巧說明
Visual C++應用程序可以識別C/C++并編譯，支持MFC類庫，并提供了一系列模板，而不是底層的建設上，這就大大加快了程序開發速度和效率，這也是Visual C++一個顯著的特點。
然而，Visual C++應用程序終究是面向過程的語言，數據和處理數據的程序是分離的。當對某段程序進行了修改或刪除時，整個程序中所有與其相關的部分都要進行相應的修改，從而程序代碼的維護比較困難。
為了避免這種情況的發生，在C的基礎上中引用了面向對象的設計方法。它是將數據及處理數據的相應函數"封裝"到一個類中，而使用類數據變量則稱為對象。在一個對象內，只有屬于該對象的函數才可以存取該對象的數據。
這樣，其他函數就不會無意中破壞它的內容，從而達到保護和隱藏數據的效果。這就是C++。當然，面向對象的C++還支持多重繼承、模板、操作符重載、內聯函數定義、預處理、宏、全局靜態類變量、嵌套類定義等等。
C++太復雜了，任何一個使用C++開發者的企業必將付出更多的成本，因為優秀的C++程序員是少而又少。基于軟件企業化的需要，人們很自然地需要一種簡單易用、面向對象。
安全靈活的"新一代Windows服務"(Next Generation Windows Services，簡寫為NGWS)應用程序的語言，于是C#出現了。它全方位簡化了C++的功能，使其具有C++所沒有的簡單易學的優勢。它既沒有C++"悲劇性"的指針概念，也沒有類似"：："、"."和"->"的"愚蠢"操作。
因此我們也可以說，C#才是程序員們所必須掌握的語言。但是，我們不能忽視這一點，語言總歸是程序員的工具，誰具有簡單易用、支持***技術并能快速有效地進行軟件開發，誰就是程序員的工具。
就目前而言，選擇C++就意味著選擇Visual C++應用程序，而不C++ Builder。這是C++程序員***件讓人頭痛的事。因為VC與Windows 98/NT同出一爐，相同功能的Visual C++應用程序編譯后，其大小要比C++ Builder小得多。不僅如此，其穩定性和完善程序要比C++ Builder要強得多。
但是"Visual C++"這個名字曾誤導了很多人，他們認為自己買了一套完全可視的編程系統，類似于Visual Basic，并在剛開始的幾天總這樣幻想。然而不久，人們認識到他們必須實際編寫和閱讀C++代碼。
雖然Visual C++向導可以節約時間和提高正確性，但程序員必須理解向導所產生的代碼，最主要的，還必須理解Microsoft Foundation Class(MFC) Library的結構和Windows操作系統的內部工作方式。
許多C/C++的DOS平臺的程序員把這種工作方式評價為"枯燥且艱深晦澀"的過程。盡管新版本的Visual C++6.0提供了控制臺應用程序類型，使DOS程序員能方便地進入MFC應用程序的開發，但仍然不能從根本上改變上述弊端。
選擇了Visual C++，就必然選擇MFC，一種程序結構，一種編程風格。但由于MFC是OWL同時代的產物，已經落后于VCL一個時代了。從開發出基于ATL的WTL可以反襯出MFC的不足。這恐怕是Visual C++程序員最窘的地方。
但我們暫且不提MFC過時的尷尬，單是稍稍地改變一下應用程序的外觀，Visual C++應用程序已是力不從心了。例如，想要改變控件的字體和背景，你得重新生成一個類，而VB只需更改一下屬性。從Visual C++界面設計的網站的火爆可見一斑。
不僅如此，Visual C++程序員也時常感到另外一種尷尬，一個小小的BMP、JPG圖片顯示，在Visual Basic中輕而易舉的事件，到了VC居然需要那么多的代碼，而且在數據庫應用程序的開發中還常發生許多一些細微的錯誤，令程序員們大為惱火。更為甚者，如果有人還想用Visual C++應用程序編寫Internet/Intranet程序的話，那簡直就是自尋煩惱。
雖然，一個優秀Visual C++應用程序的薪水要比其他程序員高。但是，他所花費的精力不是其他程序員能比擬的，他不僅需要承擔高昂的培訓費，而且還要承擔90%不成功的概率。這恐怕是想成為Visual C++程序員的人最苦惱的事。
當然，我們不是勸你放棄使用Visual C++應用程序，相反還十分支持。因為使用C/C++編寫的程序結構和算法能被更多人接受，畢竟C影響了整整20個年頭。但是時過今天，我們還能靠它來"謀生"嗎？
相信你已經有了自己的答案。當然，我們之所以跳出來，是希望程序員們不單是在這個方面去思考，更主要的是：在我們國家軟件發展浪潮到來的今天，我們不能再盲從，我們應該關注軟件產業、關注互聯網產業、關注信息產業。我們也應該有自己的歸宿，難道印度軟件大國給我們的啟示還不夠多嗎？
【編輯推薦】
