（非原創，網路摘抄）
跨平台的c++ gui工具庫很多，可是應用廣泛的也就那麼幾個，qt、wxwidgets便是其中的翹楚
這裡把gtk+排除在外，以c實現物件導向，上手相當困難，而且windows平台下執行相當慢且不穩定。
qt和wxwidgets各有各的優點，也各有各的缺點，各有各的適合應用點。
工作環境和愛好限制，個人曾經分別使用過qt和wxwidgets，
到現在，就個人而言，選擇在一般程式方向採用wxwidgets，在手機應用程式方向採用qt。
先說版權：
qt，是芬蘭的trolltech公司研發的，現在屬於nokia，一直奉行的是雙license策略，乙個是商業版，乙個是免費版：商業版的license就不說了，免費版的license，4.5版本之前一直採用gpl，意味著採用qt的程式要麼是商業軟體，要麼就是gpl軟體，這就造成了雖然出了個著名的kde，可惜應用範圍還是受限，否則的話，應用應該更廣闊點；不過還好，nokia收購了之後意識到這個問題，4.5版本之後採用了lgpl，其他開發人員可以發布基於免費qt庫連線的商業軟體了。
wxwidgets，一直奉行的是lgpl license。
再評評各自的優缺點：
qt，一直以來開發公司作為商業公司進行運作，以客戶需求為目標，提供了一系列完整的文件和rad工具，並提供最為完整的平台支援；
對開發人員而言，qt庫本身，也是所有的gui工具庫中最為物件導向化的，同時也是最為穩定的。
羅列一下：
qt的優點：
1. 支援的平台最多
2. 商業化支援
3. 完整的文件和rad工具
4. 最為物件導向
5. 世界上最為成功的手機廠商支撐，對於移動終端的支援最為完善
qt的缺點：
1. 使用的是非標準c++
2. 每個平台不是"native gui"
3. 過於龐大且執行緩慢
4. 與其它庫不是很相容（主要是stl之類的相容問題）
5. 基本只能使用特定的qmake工具（其它工具經過良好的修改也可以，不過相當於重新編寫乙個qmake，是否值得）
wxwidgets，一直以來的lgpl發布，相當開放，積累了相當一部分研究使用者，與現有各類工具庫無縫連線地非常好；
同時可惜的是沒有非常強大的正規商業化運作，可靠性、資源豐富性遠比不上qt。
還是羅列一下：
wxwidgets的優點：
1. 開放，對於各類第三方庫的良好相容（tao工具中的naming_service viewer就是採用wxwidgets的）
2. 支援各平台的"native gui"
3. 雖然有龐大的庫，執行效果極為顯著
4. 對各類現有工具的支援（筆者就採用mpc一站式產生所有專案的編譯工程）
5. 偏mfc，對於windows平台mfc程式的跨平台遷移，具有天然的優勢
6. xrc，則提供了**和設計分離的便利，程式設計師專注整體開發，ui設計群體則提供執行期介面、多語言版本支援功能等
wxwidgets的缺點：
1. 由於是偏mfc，則物件導向封裝做得不是非常好
2. 相對缺乏的文件、資源
3. 缺乏很好的商業化支援，如果商業軟體出問題需要支援，稍微麻煩點
總之：在採用第三方工具庫的複雜pc應用環境，有一定的底子，wxwidgets是不二的選擇
在只需採用qt單一工具庫的應用環境，qt是個不錯的選擇；特別是類似於手機這種嵌入式裝置環境，由於nokia的加入，qt更值得一用。
wxWidgets和QT之間的選擇
跨平台的c gui工具庫很多，可是應用廣泛的也就那麼幾個，qt wxwidgets便是其中的翹楚。這裡把gtk 排除在外，以c實現物件導向，上手相當困難，而且windows平台下執行相當慢且不穩定。qt和wxwidgets各有各的優點，也各有各的缺點，各有各的適合應用點。工作環境和愛好限制，個人曾經...
qt 的父子之間的關係
qt 物件間可以存在父子關係 每乙個物件都儲存有它所有子物件的指標 每乙個物件都有乙個指向其父物件的指標 當指定qt物件的父物件時 include include include void test void int main 輸出結果 使用qt開發時,不僅要時刻注意記憶體洩露的問題,還要時刻關注物...
wxWidgets的資源讀取
快樂蝦http blog.csdn.net lights joy lights hb165.com 本文適用於 wxwidgets 2.8.8 vs2008 windows xp在vc 下使用資源，通常都是先在 resource.h 中定義乙個整數，比如 define idi lightning r...