## 1.8為什么選擇 Qt 前面說了這么多 Qt 的介紹，相信一定有很多朋友還是要問，那么我們為什么要選擇 Qt 做開發呢，它到底有哪些突出的優勢呢，下面就是筆者給出的答案。 + Qt 是基于 C++ 的一種語言擴展(Extention) C/C++ 目前還是一種很多人都在學習的語言. Qt 的好處就在于 Qt 本身可以被稱作是一 種 C++ 的延伸。Qt 的類都是用 C++ 寫出來的。這也就是說, Qt 本身已經繼承了 C++的快 速、簡易、面向對象等許多的優點。 + Qt 具有非常好的可移植性（Portable） Qt 不只是可以在 Linux 中運行，也同樣可以運行在 Microsoft Windows 、Mac OS X 等多種不同的平臺中。這也意味者 ,利用 Qt 編寫出來的應用程序,在幾乎不用修改的情況下, 就可以同時在多種平臺中運行。 Qt 的應用非常之廣泛，從 Linux 到 Windows ，從 x86到 Embedded 等都有大量 Qt 應用的成功范例。 + Qt 支持跨平臺構建（Cross-Platform Builds） 編寫用于多平臺的軟件是單調乏味的，且可能隨時出現錯誤。維護編制文件更是如此，尤其是當不同的編譯器和平臺組合需要若干個編制文件時。通過 qmake 工具，Qt 能夠很好地面對這一挑戰。這個工具可以為目標平臺生成準確無誤的編制文件。 + Qt 是開源軟件(Open Source) Qt 產品提供的是采用雙重授權的軟件許可模式。在該雙重授權模式下， Qt 產品不僅可 在獲得商業許可下針對專利軟件開發，而且還可以在 GPL（通用公共許可證，版本 2 或版本 3）下用于開發免費和開源軟件。 + Qt 架構健壯，性能強大(powerful) Qt 已由成千上萬商業與開放源應用程序員，在多個操作系統與編譯器上進行了測試， 奠定了高性能應用程序的基礎。此外，Qt 運行時無需依賴“虛擬器”，模擬層或大容量的運行時間環境。它如本地化的應用程序一樣，能夠直接寫入低級的圖形函數，因而使用 Qt 開發的應用程序能以源代碼速度執行。 + Qt 使用起來簡便高效（concise） Qt 統一的跨平臺 API 讓程序員們集中精力致力于可增值的技術革新，而無須擔心維護 和管理現有應用程序多版本的基礎結構與界面。 因此 Qt 開發人員僅需要學會一種 API 來 寫入應用程序，該程序便可在任何地方運行。 Qt Software 投入了相當大的努力使得 Qt 使用起來盡可能簡單和直觀。來自世界各地 的客戶反饋普遍認為 Qt 編程簡單而有趣；而對于商務應用而言， Qt 可以轉換為更多的功 能，并且在保持質量性能的情況下，只需更少的維護工作。 總之，Qt 可以跨平臺、不依賴虛擬機機制，速度和性能不會比同類型的 Java, .NET(C#)差，這就是程序員選擇 Qt 的最直接的理由了。 閱讀材料 GTK+, Qt, wxWidgets 比較簡評 這位來自臺灣的朋友把 GTK+, Qt, wxWidgets 比較分析得相當到位。很明顯的，MFC 注 定將淡出江湖了。下面就是幾個跨平臺庫的橫向比較。 之前因為把 MFC 痛罵了一頓，有網友在詢問其它 GUI toolkit 的相關事項，所以小弟 分享一下個人對三大知名圖形界面庫的簡短評論，以下純屬個人主觀意見，不是專業人士， 所知有限，望前輩不吝指正或補充。 1\.先講 GTK+ GTK+ 主要用在 X Window 上，整個設計的架構和許多概念和 MFC 以及一般 Windows 上的程式開發大異其趣，入門門檻較高，而且最主要的特色是，它用不具有物件功能的純 "C" 語言，模擬物件導向。 所以寫起來比較復雜艱澀，而且充滿大量巨集，使用和除錯都 不是很容易，但優點則是可以用 C，不需 C++，如果和 Win32 SDK 比較，不會難學多少， 缺點是不易上手使用，而且文件比較缺，架構又非常復雜，且提供的東西比起其它無所不包 的 library，是簡陋了一點，函數命名又臭又長。對于簡單的程式， GTK+會顯得太復雜，但 是當你開始想擴充其它 library 也都沒提供的進階功能，就會開始贊嘆 GTK+ 的架構嚴 謹，還有超乎想象的高度彈性。同樣的東西要用 MFC 來做反而會要人命，並且對多國語言 的支援良好，內部也全面使用 UTF-8，相容性好，又是 unicode。能夠習慣的話，GTK+ 值 得推薦，但沒有很建議學，畢竟不好學，要用到熟會需要比較久，而且那樣很多 C++ 的功 能會用不到。 GTK+ 有 C++ 版本叫做 GTK--，沒用過，但看文件覺得，并沒有比 gtk+ 簡 單到那里去。 因為 gtk+ 本來就是物件導向，所以即使換了 c++ 語言，寫起來架構還是差 不多的。 另外，gtk+ 有 Windows 版本，但缺點是，執行緩慢，不穩定，而且界面是使用 gtk+ 自己的，不是使用 Windows 內建的"Native" 原生圖形界面，看起來會不太習慣。 Mac OS X 下可用 X11 來執行 gtk+，但那樣出來的程式是長得像 UNIX 程式，而不是美美 的 OS X Aqua 外觀。 2\.再說 wxWidgets wxWidgets 和 MFC 最接近，命名習慣或架構都高度相似，會 MFC 的話幾乎不用重新學 習。它有十余年歷史，此外，它的物件封裝比 MFC 要好，提供的功能也多上太多，又跨平 臺。一般知名的 MFC 程式都會選擇用 wxWidgets 改寫，來快速移植原程式到其他平臺。例 如， eMule 用 wxWidgets 移植出 aMule, xMule, 還在開發中的 Filezilla 3...等。而它 最主要的特色是，它是"跨平臺"的 "Native" GUI toolkit，在各種平臺上都可寫出使用該 平臺內建 Native 原生圖形界面的程式。 在 Windows 上就長得跟其他 Windows 程式一 樣，在 Linux 下就使用 gtk+ 的圖形界面，在 Mac OS X 下就可以使用華麗的 Aqua 外觀 風格，這點是非常強悍。 不像 gtk+ 到其它系統都還是只能用 gtk+ 自己的。缺點是，中 文支援在有些地方會出問題，例如剪貼簿的操作，得自己 patch。但仍然相當推薦，即使是 個龐大的 library，效能依舊不會太差，尤其在 Windows 上執行速度并不輸 MFC，與其學 MFC，不如學 wxWidgets。 3\.最后看看 Qt Qt 的功能，應該是這三者加上 MFC 之中最強大的，文件也很完整，又有 RAD 工具可 以輔助開發，并且有商業公司做強力后盾。不但有 Windows/X Window/Mac 版本，甚至還有 嵌入式系統可用的版本，穩定性還不錯，物件封裝也算良好，資源比 GTK+ 或 wxWidgets 多得非常多，而且發行公司提供了相當多范例，算是一家以開放原始碼成功贏利的模范公 司。 知名的 KDE 整個是用它開發，證明了它的穩定性和強大功能。缺點是如果你用它開發 非 GPL 開放程式碼的軟體，必須以極昂貴的金額，購買商業版本。 而它的圖形界面并不完 全是 "Native GUI"，只是透過 theme 去模擬系統上的標準 GUI，所以看起來很像，卻會有 些地方可以明顯看出破綻。 執行速度緩慢還有過于龐大則是另一個問題。 雖然封裝得很良 好文件也齊全，并不代表他就很容易學還有一個嚴重問題是，它寫的不是標準 C++，它使用 的 signal/slot 機制必須透過 Qt 提供的 preprocessor 處理過才可以轉送給編譯器，這 部份可能被限定用 qmake，算是一個可惜的地方，不過暇不掩瑜，還是很推薦。忘了說，它 內部也是 unicode，多國語言沒問題。 以上三套只是簡單介紹，其中 Qt 的程式我沒有實際完整開發過，但明顯的三套都遠 遠比只能在 Windows 上用，功能少 Bug 多，難學難用，幾乎無多國語言支援的 MFC 要 強。三套可跨平臺的 library 大家可自行選擇，只能用在 Windows 的 MFC 就不用考慮 了。 這篇短評發表出來有些時日了，其中的有些觀點（比如 Qt 的授權問題）已經落后于現 在的 Qt 的發展，但其中的大部分論據仍然極有說服力，清晰而簡明的指出了幾大類庫的優 缺點，讀者朋友可以從中獲益。