C++ Builder的前身是Borland C++，Borland C++ 所使用的 application Framework是OWL，而OWL以物件導向的角度來看，也的確比MFC先進很多（這在學界早有定論），但是在市場上卻叫好不叫座，直到ImPRise（以前的Borland）推出以VCL為Application Framework的Delphi之後，這才一炮而紅。
C++ Builder的Compiler在功能上跟Visual C++都一樣，Win32 API等都可以呼叫與使用（VCL就是架構在Win32 API之上，沒有不相容的問題，只是包裝的更高明，也非常有彈性），你不用擔心目前有什麼事情是Visual C++可以做而C++ Builder做不到的，進而拒絕使用C++ Builder，抱持這樣的觀點就似乎為了健康而不坐汽車，卻堅持騎腳踏車從淡水來上班一樣因噎廢食，在網路許多非常有經驗的程式設計師會告訴你這是多慮了。曾有人比喻的很傳神，假如Visual C++是手排車，那C++ Builder就是手自排兩用車（看過三菱的Sportsmode手自排兩用車嗎？）。
C++ Builder的程式設計細節是清楚而透明的，除了Application Framework的運作保有神秘感之外（MFC也是），所有的程式碼與檔案相關的檔案都是可以把握與觀看的，不像某些開發工具，程式設計師許多事情是無法把握的，而C++ Builder 所產生的碼大小與產生的時間都和Visual C++ 都是同級的（我指的是勝敗差距都不大，到要一提的是，C++ Builder 3.0采用一種技術，可以使得第二次以後的Compiling速度提升五倍以上，筆者可以證實這一點）。
除了某些非凡需求的專案之外（例如版本升級，而原來的版本是VC開發的，或者參考改寫的程式碼是用VC寫的，事實上C++ Builder也可以支援MFC），我看不出來公司有什麼專案的規模或內容非要靠Visual C++不可，自己找罪受不說，也違反了“Build a high performance company“的目標，而將大量的資源投注在落後的工具上，程式生產力也無法巨幅提升。因此我建議公司應該大量而全面性的鼓勵員工使用并熟悉C++ Builder成為第一線的程式開發工具，根據我的淺見，這樣的投資不但回收快速，而且效果宏大。
簡而言之，C++ Builder同時兼具C++程式語言的威力和Visual Basic這種 Rapid Development Tool的視覺化程式開發環境的便利，土法煉鋼或必先利其器，決定就在你了。
