網上有很多各種編譯器的優劣比較的東西，我寫這些東西並不是想支持或否定某些東西，因為我始終認為在編程的領域中，我只是一個初學者，並沒有資格來評判什麼（況且我也不想去評判），我只是想講述一下個人學習道路上的感受。
學編程的一個必備的條件是你要有一個實踐的平台--一個相應的編譯器，沒有這個條件，一切都是空談。選擇編譯器之前，首先選擇的是語言（這個我想不必更多的解釋了），這裡我假設你選擇了C或C++。
現在最流行的編譯器恐怕應該是微軟的VC了，在繼續之前，我想再提一下一個重點：VC是一個編譯器，只是一個用來把C++的代碼生成為可執行文件的工具而已（當然我說的有一些簡化，但是認識這一點很重要，雖然你可以在很多地方看到類似的話，但我還是要提，我希望每一個學習編程的人最好從一開始就知道它，而不是走了很多彎路以後再來醒悟）。另外一種強大的編譯器就是Borland C++ Builder（後面我都將以BCB來代替）。
如果你在使用VC，我想問一下，你為什麼用它？我想很多人根本無法回答這個問題，大多無法回答的原因很明顯：1）聽說的，VC是最好的；2）微軟的產品；3）只知道這個。當然更有甚者是一開始就把VC作為一門語言來學，呵呵，我相信一定有這樣的人的！每當談及這些問題的時候，我會覺得很多時候，軟件行業中技術並不是優秀軟件的全部，VC一定是最好的麼？VC為什麼會這麼成功？我不得不佩服微軟的商業策略。關於VC是如何成功的，我強烈推薦一篇文章--《C/C++聖戰》，作者李維，《程序員》雜志2001.10月。
一個編譯器究竟帶給我們什麼？在早期，編譯器其實就是一個簡單的文本編輯器+庫（頭）文件+編譯程序，很多早期的程序員會使用一些其他的編輯器來書寫自己的程序，然後再使用編譯器來編譯。現在我們使用的編譯器通常稱為集成開發環境（IDE），這一類型的開發環境為我們提供了很多東西：方便的開發方式、完善的幫助系統、豐富的庫和一些特有的特性。
在某個特定的平台下編程你需要關心的主要有兩件事情：1.是否支持你所使用的語言；2.平台特性（WINDOWS下platform sdk為我們提供了一切）。在WINDOWS平台下，我們可以使用C++來編程，剩下的就是平台特性了。WINDOWS為我們提供了一系列豐富的API函數，而且這些函數在不同的WINDOWS版本上會略有不同。早期的WIDNOWS編譯器就是在單純的C/C++編譯器中對平台特性提供支持，並沒有提供更多的東西，如果你只打算使用WINDOWS API的話，編譯器的選擇可能只是編譯優化程度的選擇而已（也許你該選擇BCB，據說要比VC優化的好一些，我沒有真實的數據來對比，但BORLAND公司的編譯器優化一向被認為是優秀的）。真正產生變化的是類庫封裝的開始。微軟提供了MFC類庫，BORLAND提供了OWL類庫。所謂類庫就是提供了對WINDOWS API的一種封裝，相信每個寫過WINDOWS API程序的人都有一個體會，一個最簡單的WINDOWS窗口程序都需要幾十行代碼，這足以令初學者望而卻步，相比之下DOS下的經典例程"hello world"卻只需要短短的一行代碼（所以DOS時代才令我懷念--簡單，明了。呵呵）。類庫的出現正是為了解決這個問題，WINDOWS類庫主要是對WINDOWS下的API函數進行封裝，來達到這樣的目的：1）簡化我們編程過程中的重復的簡單工作（只創建窗口、建立消息環這樣的單調工作）；2）使我們的工作更符合面向對象的風格。如一個MFC中的窗口：
CWnd MyWindow;
MyWindow.Create(…);//這裡省略了參數
我們只需要創建一個窗口對象，通過對象的Create方法來創建窗口就可以了，完全不必再去關心底層的一些東西，整個過程就象工廠的一個生產過程--這也正是面向對象的精神所在（如果你現在不能體會這一點，不用著急，以後慢慢的自然會明白的）。
聽起來都是頓悟的例子。難道學習COM/OLE特別需要宗教信仰嗎？我想是因為這些技術特別需要高度抽象思考，使得霍然開朗後的喜悅巨大到令人覺得是一種「突然的神跡降臨」。其實你我都明白不過，知識點的突破，是靠知識面的累積。
很多時候，當你回頭去想以前的不明白問題的時候，你是否有這樣的感覺？我相信答案是肯定的。我想問題的關鍵就在上面一段話的結尾：知識點的突破，是靠知識面的累積 對我來講，當我接觸了BCB之後的一段時間，我突然就明白了，它和VC僅僅是提供了一個封裝了不同類庫的編譯器而已，真正關鍵的問題是C++呀！也正是在這以後，我才真正開始入門，而這都是我學習編程一年多以後的事情了。如果沒有那個偶然的機會，我接觸過一次BCB，也許到現在我還無法分清楚那些是VC提供的、那些是標准C++提供的。與C++相比，MFC和OWL變得微不足道了（我沒有小看它們的意思）。
我希望所有的人都不要重復我走過的學習之路，我的路是曲折的，至少在學習的過程中我浪費了很多時間（我曾經幼稚的認為現在的編程只是進行功能的擴充而已，如WINDOWS SDK等，完全忽略了面向對象的思想存在）。我一直認為VC是一個優秀的編譯器，但是當你構建一個MFC程序的時候，很多書籍介紹的入門方式顯得相對松散，給你的感覺是在使用一個龐大的WINDOWS函數庫而不是一個類庫，許多教科書忽略了MFC中面向對象概念的加強，而僅僅是一些功能上的實現，而在BCB中，面向對象的思想相對要強化一些。
我寫這些並不是想說明什麼樣的編譯器好和什麼樣的編譯器不好，最終的選擇權可能不在你我的手中，很多時候是平台或其他因素的限制而導致你必須使用某種編譯器。我只是想說明一些思想，因為我無法把我想說明的這些問題提煉出來，所以松散的寫了很多，最終我想說的就是不要因為一些不必要的原因去拒絕--Never！
以上內容僅代表個人觀點，如有不當，歡迎討論。
VC和BCB采用了各自不同的方式（MFC和OWL）來封裝，大家采用的手段各有所長，很難說哪個更好，唯一讓MFC占優的應該是操作系統的優勢了。相比之下，我個人認為起碼在程序生成的環節上，BCB要好一些（其實BCB我個人也是浏覽過一下，總共時間不過2-3天，只是做一次了解而已），在VC中，如果你為一個通用控件如CListCtrl關聯一個變量，寫過程序的人應該知道，編譯器會作為一個類成員變量生成，而在BCB中，這個變量是以類成員指針的方式存在的，有什麼區別呢？大量的局部變量會造成堆棧的溢出，這也是為什麼你無法創建一個char largestr[100000000]的原因了。如果你在VC的程序中使用了很多這樣的變量的話，天知道會怎麼樣（雖然堆棧中的變量存取更有效率）。
在一段時間以前，我也具有很多非常糟糕而幼稚的想法，直到某一天，我明白了很多。其實許多學計算機的人都會有相同的感受，以下的一段摘自候捷先生的散文：
南宗與北宗，頓悟與漸悟
佛法有頓悟，學問可沒有。如果有人說，我突然在某一天對Java開悟了，對OO開悟了，對MFC開悟了...，我想那是他刻意（為了炫耀）或非刻意（因為遺忘）地忽略了他所謂的「悟」那一天之前的所有努力。是的，那叫漸悟，不是頓悟。
Inside OLE 一書作者 Kraig Brockschmidt 在他的序裡面有這段話：
1993年一月的某個周日下午，當我正做著與OLE全然無關的事情時，我突然獲得了所謂的 OLE 涅磐狀態。所有關於OLE的支支節節突然全都歸定位。在六個月的模糊心智之後，我突然看清楚了OLE。
Essential COM一書作者Don Box在他的序裡面亦有一段類似的話：
幸運的是有一天（1998年八月八日），突然像神跡一般，COM對我變得再明白不過，我終於了解了COM的動機。如何把這個programming model應用在每天遇到的程式設計問題中，也因此顯得再明白不過。
