請問各位先進!! Borland C Builder X 據官方說法似乎已經取消VCL套件功能!! 那是不是就不支援直接拉GUI的功能啦!! 因為小弟 一直找不到Frame的選項 所以.....就不知道怎麼拉GUI@@ 該不會跟 VC一樣 要DIY編排介面阿 希望各位先進 能不吝賜教!!

Borland C BuilderX 問題回答 左輕侯2003.10.20 引述http://www.csdn.net/develop/article/21/21877.shtm 在Borland發佈C BuilderX前後的這一段時間裡，我在CSDN上陸續看到了不少關於C BuilderX（以下簡稱CBX）的討論。作為Borland中國公司負責快速開發工具和開發者社群關係的工程師，我認為我有必要對大家的一些疑問和猜測進行回答。 需要說明的是，我並沒有得到Borland公司的正式授權來做這個回答，因此下列文字，不一定等同於Borland公司的官方觀點；我只是把從我這個角度看到的一些東西，盡量和大家進行溝通。如有錯誤或不當之處，還請不吝指正。 CBX誕生的背景 就我所見，網上對CBX的問題主要集中在這幾個方面：Borland公司出於什麼動機開發CBX，它與C Builder的關係怎樣？CBX的framework詳情如何，與VCL的關係怎樣？Borland公司對CBX的定位和長期計劃是什麼？ 要回答這些問題，首先必須從開發CBX的背景說起。 如大家所知，Borland公司在2003年發佈了一系列的新產品，其中在Windows/.NET平台的開發工具就有三個：Delphi.NET、C#Builder與CBX。這些新產品的推出，表示著Borland公司在Windows平台下的開發工具陣營發生了大的變革和分化。而這些變化的發生，又根源於操作系統本身的一次深刻的革命，即從Win32平台到.NET平台的全面過渡。 根據我的所見所聞，國內有不少技術人員仍然對這一轉變沒有足夠的認識。簡言之，Microsoft公司已經下定決心，將操作系統從Win32全面轉向.NET；逐漸地，Microsoft不會再提供新的Win32 API，未來操作系統的新功能將全部以.NET SDK的方式提供；從企業級伺服器，到桌面系統，再到嵌入式系統，.NET將是Microsoft公司解決方案中的統一的編程模型。雖然這個轉變緩慢、艱難、痛苦，但這是歷史潮流的方向。無論您是否喜歡，除非您放棄在Microsoft平台下的開發工作，否則就只能適應它。 這一轉變給Windows平台的開發工具廠商帶來了很大的挑戰，Borland公司也不例外。目前的形勢，就和當年從DOS過渡到Windows的情況差不多，整個操作系統與編程模型與發生了徹底的變革。Borland的Delphi和C Builder都深深植根於Win32平台，面對這一轉變，必須作出積極的反應，纔能求得生存和發展。Borland公司確實也做出了這種反應。 正像大家看到的那樣，Delphi的方向是和操作系統一起轉向.NET平台，其結果就是Delphi.NET的誕生，它將和全新的C#Builder一起，成為 Borland公司在.NET平台下的主力開發工具。（但Delphi仍然保留了在Win32下進行開發的能力，因為Win32平台下的應用程式在未來相當長的一段時間內會繼續存在。） 至於C Builder的方向，在Borland公司內部進行過討論，結果大家應該已經猜到了，那就是C Builder並沒有向.NET靠攏，而是堅持走原生開發工具的道路，並且延伸到了多個平台、多個編譯器。原來C Builder和Delphi一起，由同一個RAD開發小組進行開發，這也是為什麼C Builder和Delphi總是交替升級版本的原因之一。Borland在做出這個決定以後，成立了新的C /Mobile開發小組，C 開發工具從此和Delphi分道揚鑣。 Borland為什麼做出這一決定，有多種原因。首先，原生C/C 開發仍然是最重要的市場之一。在Microsoft以外的平台上，無論是服務端的Unix/Linux，還是越來越熱門的嵌入式系統，C/C 仍然是挑大樑的語言。即使在Microsoft平台下，往.NET的過渡完成以後，在某些底層的開發中C/C 仍然具有不可替代的地位。回顧Borland C 的光輝歷史，展望未來的戰略佈局，Borland都不能夠放棄這一市場。其次，C 語言有其特殊性，不適合向.NET移植。熟悉.NET平台的朋友可能知道，Delphi的許多特性與C#語言相當類似，從對像引用模型，到單根繼承結構，以及PME（property, method, event）模型，無不如此（畢竟C#和Delphi同出自於Anders之手）。對Delphi進行延伸和調整，以符合.NET CLS（Common Language Specification），並不會損害Delphi的樣式，反而有利於一個更強大的Delphi。而C 則具有完全不同的開發思想，如果要符合CLS，必須對C 進行大幅度的修改，結果是C 不再成其為C 了。Visual Studio .NET中提供的Managed C ，在C 社群中並沒有得到普遍的認同，就是一個例子。 在這種情況下，C Builder不是轉向.NET而是另闢蹊徑，不能不說是明智之舉，甚至可能是唯一的選擇。 相容性和VCL CBX的往下相容性，特別是與VCL的相容性，在網上是備受矚目的問題。 這個問題可以明確地回答如下：在CBX中，沒有VCL。CBX內接式的framework，是一個全新的、100%由C 開發的、跨平台的framework，其中的GUI部分，基於第三方的跨平台的wxWindows組件庫（GUI及相應的RAD功能在CBX 1.0中還沒有，將在2.0中提供）。 由於歷史的原因，C Builder的framework使用了Delphi的VCL。這使得C Builder的程式員往往發現自己處於一種相當尷尬的境地：他不得不與另外一種語言寫成的framework打交道。而且，為了和VCL相容，C Builder中增加了象__property這樣的非標準語法，從而使C Builder看上去像一個Delphi的複製品。因此，網上有「BCB的高手必定是Delphi的高手」的說法。從C Builder誕生的那一天開始，用C 重寫整個framework的呼聲就沒有停止過。 CBX的誕生，使得這個願望終於實現了，而且這個framework甚至超過了我們的期望：它不但完全使用標準C 寫成，而且支援跨平台和交叉編譯（Cross Compilation，即在一個平台下編譯產生另一個平台下的可執行編碼），同時也對某些專業領域，例如嵌入式開發，提供了專門的支援。另外，它還能夠方便地掛接ACE、Loki、Boost等第三方的C 庫。 但是，這種改變也有不利的一面，那就是CBX不再往下相容VCL。這是許多技術人員表示不滿的原因，因為原來的C Builder已經與VCL密不可分，CBX拋棄VCL，將會導致C Builder的程式員必須重新學習新的framework，並且給原有編碼的升級帶來很大的麻煩。許多質疑都指向同一個問題：為何Borland沒有實現VCL向C 的平滑過渡？ 這個問題確實是一個很大的問題，可以追溯到當初Borland在開發C Builder的時候，為什麼沒有用C 開發自己的framework，而是不惜修改C ，讓它使用由Object Pascal編寫的VCL；以及為什麼在C Builder的6個版本的升級過程中，一直沒有用C 重寫VCL；甚至涉及到 Delphi的設計思想與C 和Object Pascal的區別。 一般認為，Borland當初是出於時間和資金的壓力，才出此下策，讓C Builder嫁接到基於Object Pascal的VCL上。我曾經也持這種觀點，但是後來在逐步深入學習Delphi和C 的過程中，才慢慢發現，這一舉動可能有更重要的原因，那就是由於C 和Object Pascal的差異，將VCL移植到C 有著幾乎不可克服的困難。 以所謂「虛擬建立函數」為例，在C 中，建立函數不能夠是虛擬的。C 之父Bjarne Stroustrup博士曾針對此問題進行過討論：「虛擬調用是一種能夠在給定訊息不完全(given partial information)的情況下工作的機製。特別地，虛擬允許我們調用某個函數，對於這個函數，僅知道它的端口，而不知道具體的對象類型。但是要建立一個對象，您必須擁有完全的訊息。特別地，您需要知道要建立的對象的具體類型。因此，對建立函數的調用不可能是虛擬的。」但是在Object Pascal中，建立器（constructor）卻可以是虛擬的。原因是，Object Pascal的對象模型與C 不同。在Delphi中，有所謂的「類類型」（TClass），這是一個描述類的相關訊息的類，類似於C 中的type_info類，但比後者強大得多。更重要的是，Object Pascal會根據類類型來決定建立的對象，使用這種機製，它避免了「給定訊息不完全」的問題，從而輕易地實現了虛擬建立器。 同時，這種機製也導致了Object Pascal和C 中的RTTI的巨大差異：標準C 中的RTTI只能得到類名稱（編譯器可以提供額外的RTTI支援，但很有限），而Object Pascal中的RTTI不但可以得到類名稱、類繼承關係、對像實例大小，還可以取得類的內容、方法、事件等訊息。Delphi中的這種RTTI類似於Java/C#中的Reflection，或者也許可以反過來說，Java/C#中的Reflection受到了Object Pascal的影響。Object Pascal之所以能做到這一點，又離不開它的單根繼承結構：由於Object Pascal中所有的類都繼承自TObject，因此可以輕易地增加RTTI訊息。在這一點上，C 和它又有著本質的區別。 在VCL的來源碼中，大量地使用了類類型和虛擬建立的技術來構建龐大的繼承樹，而強大的RTTI則更是整個Delphi組件模型的基礎。如前所述，由於Object Pascal和C 在語言上的差異，要用C 依樣畫葫蘆地重寫一遍VCL，根本就是不可能做到的事情。說到底，這已經是業界兩種不同的編程思想之間的差異，不是簡單地折衷一下就可以混合的。 讓我們把這件事放到更大的歷史背景中來看。Anders開發Delphi的時候，正是C 借助OOP思想快速成長，而Pascal語言日趨沒落的時候。Anders不但果斷地突破了標準Pascal的限製，將OOP全面引入到新的Object Pascal中，而且針對C 在實踐中暴露出來的一些問題，有意識地進行了彌補和改進，以構建新一代的framework。這一行動的結晶就是VCL的誕生。事實上，Object Pascal/VCL的許多經驗，後來也被Java/C#所汲取，用於構建J2EE/.NET中的組件架構。從這個過程，我們可以看到編程思想與編程語言的演化。 當然，這並不是說C 就已經沒落過時。事實上C 也一直在不斷的成長中，上述的問題，可能有別的解決途徑。拿「虛擬建立函數」來說，Stroustrup本人就指出，可以使用工廠模式（factory pattern）來間接實現。用C 構建一個功能上類似VCL的framework，是完全可以做到的，但是實現後的產物，肯定與Object Pascal寫成的VCL大相逕庭。其實這已經與C Builder程式員們的初衷相去甚遠了。我認為，這才是Borland權衡利弊，最後不惜損害C 的相容性，把C Builder嫁接到VCL上的主要原因。 考慮到這些因素以後，VCL沒有在CBX中延續其生命就是很容易理解的了。另外一個重要原因是，VCL是在Windows平台上發展起來的，因此很多地方都只考慮到跟Windows平台的集成。Borland既然已經決定另起爐灶，打造一個完全跨平台的C 開發工具，自然會趁此機會，擺脫與VCL扯不斷理還亂的關係，用全新的、100%C 的framework取而代之。 IDE CBX將使用JBuilder的IDE，這一消息現在已經得到了證實。為什麼C 開發工具卻要使用一個用Java寫成的IDE？這也是引起許多朋友質疑的地方。 CBX選用JBuilder的IDE，至少部分是由於統一IDE的需要。眾所周知，Borland作為一個平台中立的廠商，在很多平台上都有自己的開發工具，隨著這些開發工具的發展與分化，統一IDE已經是不可避免的趨勢。據稱，Borland以後將只維護兩個基本的IDE，即基於.NET的Galileo和基於Java的PrimeTime。C#Builder和Delphi.NET基於前者，JBuilder則基於後者。CBX作為一個以跨平台為重要特徵的開發工具，選擇後者作為IDE是順理成章的事情。 事實上，當我們把眼界放開闊後，就會很容易地發現，統一的IDE已經成為業界的一股潮流。Microsoft在Visual Studio.NET中提供了統一的IDE，同時支援VC#、VB.NET和VC .NET等多種語言。IBM主持下的Java IDE項目Eclipse，宣稱以後將以CDT（C/C Development Toolkit，用於Eclipse的C/C 開發工具箱）為重要的發展方向。SUN的NetBeans則早已將C/C 納入支援的範圍。可以說，用執行於Java/.NET這樣的受管製編碼（Managed Code）之上的IDE來作為C/C 的開發環境，並非Borland的首創，反而是順應潮流之舉。 另外，以我的個人意見，JBuilder的IDE確實要比Delphi/C Builder強上很多。雖然JBuilder背有速度緩慢的惡名，但是在硬體條件能夠保證的情況下，它的CodeInsight、Code Template以及Refactoring等功能，比Delphi/C Builder明顯領先，更不用說對UML的支援以及和Together Edition for C 的集成。因此，我認為CBX借用JBuilder成熟強大的IDE，是一件好事。 C 的未來 讓我們暫時拋開CBX，來看看C 語言本身的一些東西。 毫無疑問，C 仍然是最主要的工業語言標準之一，特別是近幾年來，C 語言出現了蓬勃的發展，各種新技術和新概念層出不窮，世界範圍內的C 社群也是蒸蒸日上。但是，勿庸諱言的是，C 的地位確實受到了來自Java/C#的有力挑戰。在應用領域、特別是在高階的應用領域中，Java正在逐漸取代C 成為主流。 導致這種情況的原因是多樣的，但最主要的原因有兩個。一個是C 的標準推出太晚，直到1998年ISO C 標準才正式推出，在此之前，各種樣式的C 版本把時間浪費在內耗上，將大片的市場拱手讓給了Java。另一個更重要的原因是，雖然ISO C 標準的製定統一了C 的語言，但是卻沒有統一C 的framework。雖然C 標榜自己是平台無關的語言（它的確也是），但是對於同一個問題，在不同的平台下有各種不同的解決方案。C 自己的標準庫只是一個語言的framework，而不是一個應用的framework：在I/O，多線程，Socket，GUI，資料對像模型等等常見的問題上，開發者們不得不要麼自己封裝特定平台的API，要麼尋找難以保證質量的第三方類庫。沒有統一framework的C ，就像沒有VCL的Delphi，沒有JFC的Java，沒有.NET framework的C#。因此毫不奇怪，C 在應用領域無法與Java/C#抗衡，而逐漸退守到底層編程。 去年10月，Bjarne Stroustrup博士訪華的時候，我曾經當面向他提出過這個問題：為什麼C 沒有一個統一的、跨平台的、面向應用的framework？C 的標準庫是否有向這個方面努力的計劃？Stroustrup博士嚴肅地回答了這個問題。他說，與Delphi、Java、C#不同的是，C 是一種廠商中立的語言，它的標準掌握在ISO C 委員會手中。這固然保證了C 的純潔性，但也導致了沒有廠商投入大量的資源來開發一個統一的framework——即使有廠商這麼做了，也不一定能夠保證它的權威性。最後，他建議我可以考慮利用一些優秀的第三方庫。 由於這個問題涉及到很多技術之外的因素，甚至涉及到C 本身的目標和定位，看來沒有也不會有更好的解決辦法了。誰知沒過多長時間，事情突然出現了轉機。Borland的C BuilderX，不正是在試圖扮演一種這樣的角色嗎？ 從背景來看，Borland作為老牌的開發工具廠商，在C 編譯器和framework的開發方面的技術和經驗是無可置疑的。而Borland往日最大的競爭對手Microsoft已經明顯地將重心轉移到.NET和C#，不會再大幅度地發展原生的Visual C ，更不會去開發面向應用的C framework。因此，Borland等於接收了Microsoft轉型後留下的真空。同時，Borland也是業界具有領導地位的軟體公司中，唯一一家完全平台中立的公司，這和C 的宗旨是相稱的；由它來完成一個真正跨平台的C framework，真是再合適不過了。或者反過來說，除了Borland，業界很可能不會再有一家廠商會來承擔這一工作。 從目前看到的產品來說，CBX確實在各方面都達到了目標。統一的、跨平台的、符合ISO C 標準的framework（包括用於RAD的GUI解決方案）；跨平台的IDE；支援多種編譯器；支援交叉編譯；跨平台的資料庫訪問引擎（dbExpress）；對移動裝置開發的解決方案；對Boost、ACE、Loki等第三方C 庫的開放式支援；再加上與Together Edition for C BuilderX的集成，引入了令人激動的MDA開發方式；即使是Stroustrup本人，恐怕也難想像比這更好的C 了。 第一次見到CBX的展示的時候，確實很給人震撼的感覺。我曾經和包括公司同事在內的一些朋友熱烈地討論過，一旦CBX成功，會產生什麼樣的後果？在一個統一的、跨平台的framework的影響力之下，C 是否會重返應用領域？Java/C#的市場是否會因此受到衝擊？不僅是Borland C 這個令人難忘的名稱，而且是整個C 世界，是否都會契此機會東山再起，重振聲威？一切都有待市場的檢驗。

bipolet你好： 我想下面這一段話回答了你的問題： ”在CBX中，沒有VCL。CBX內接式的framework，是一個全新的、100%由C 開發的、跨平台的framework，其中的GUI部分，基於第三方的跨平台的wxWindows組件庫（GUI及相應的RAD功能在CBX 1.0中還沒有，將在2.0中提供）。”

感謝 pwipwi大大!!    小弟已經有一定的了解了!!  謝謝!!    不過也感到自己實力的薄弱， 只知道怎樣Coding，卻不知整個語言的變化與潮流 平平24歲，那ㄟ差架多  !!@@    pwipwi大大的文章  對小弟有很大的幫助 真的很謝謝你  

感謝 pwipwi大大 提供的資料... 原來 wxWidgets 是跨平台的!! http://www.wxwidgets.org/ 看起來似乎應該花一些時間在它上面... 當初 BCBX 出來時，只注意到它沒有 GUI 元件，所以不太可能使用它... 因為... 等於要像玩 VC 一樣，那不如去玩 VC， 它應該多多推 wxWidgets 這樣才知道有其他簡易的方式來作 GUI， 不然，除非已熟 VC 或沒有 RAD 介面的 C++，純以系統 API 來寫程式， 是很累的...    To bipolet, 我都三十好幾了，我也都不知道潮流與變化... < href="http://free.greenworld.com.tw/~dllee/" target="blank">吃軟也吃硬 dllee.ktop.com.tw StatPlus 系統資源監測器 @ KTOP VMASK - ViewMove Automation Software Kernel

------
http://www.ViewMove.com

雖然wxWidgets是跨平台的， 但是我看到wxWidget的Example和架構時， 總覺感覺他和MFC實在很像， 一直不想投入....。 平常vcl用習慣了，還真的是"被寵壞"

以  Boost http://www.boost.org/ Loki http://sourceforge.net/projects/loki-lib 都算是跨平台的函式庫(非GUI)，再配合跨平台的GUI wxWidgets http://www.wxwindows.org/ 確實是很不錯，但算是三個獨立的套件，每個在元件命名上， 及函式使用上就會覺得沒有像 VCL 來得一致，再加上像您說的

引言:平常vcl用習慣了，還真的是"被寵壞"< face="Verdana, Arial, Helvetica"> 只要看到原始碼內一大堆

<< XX::YY::ZZ   >>

就會覺得很像 VC/MFC 而且不易讀，以這些來說，如果是用一套 基本已完整的套件，其 namespace 在一開始就有初步規劃， 就可以減少重覆的問題，就像我們在使用 BCB 幾乎只有 3% 不到的 code 需要特別加上 namespace，程式碼也易讀了許多。 再者三個套件三種不同的 License... 用起來也是怪怪的... Release 一個程式結果可能有一半的說明文件必需是別人的 License 在之前 > 如果真的 href="http://free.greenworld.com.tw/~dllee/" target="blank">吃軟也吃硬 dllee.ktop.com.tw StatPlus 系統資源監測器 @ KTOP VMASK - ViewMove Automation Software Kernel