幫助文檔

用戶選擇圖形開發環境的時候，幫助文檔是否周全是左右其選擇的重要因素。Visual開發環境的幫助文檔MSDN(這個還要單獨掏錢購買)非常的龐大，有10個CDROM光盤。它包羅萬象，涵蓋廣泛。但是難免有泥沙俱下，主題模糊，關鍵信息不突出的遺憾。其鏈接設計的也很糟糕，通過鏈接很難從一個類跳轉到其父類或者子類以及相關的類。如果你搜索一個關鍵字，不管是Visual C++、Visual J++、Visual Basic，只要包含這些關鍵字的信息統統的返回來。

Qt的文檔設計的相當優秀，其文檔完備且詳細的覆蓋了Qt的方方面面，竟然僅有18M。每一個類和方法都被詳盡描述，巨細靡遺，舉例充實。

Unicode

使用MFC，如果要顯示unicode，在編譯鏈接時必須用到特殊的參數(和改變可執行文件執行的入口)，必須在每個string前面加上T，將char修改成TCHAR，每個字符串處理函數(strcpy(), strdup(), strcat()...... )都要改變成另外的函數名。更令人惱火的是支持Unicode的軟件竟然不能并不支持和Unicode的DLL一起工作。當使用外部DLL來開發的時候這是個很嚴重的問題，但是你毫無選擇。

使用Qt，字符串用QString來處理，其本身是與生俱來的Unicode，不需要改變什么東西。不要在編譯/鏈接時增添參數，不要修改代碼，只需要使用QString就可以了。QSting類功能強大，你可以廣泛地使用它，并且不要擔心Unicode問題，這使得轉換為Unicode非常的方便。QSting提供了轉換為char ＊ 和UTF8的函數。顯然，MFC的CString的設計相比于Qt的QString設計有著巨大的不同。CString以char ＊為基礎提供了很少的功能。它的優點是當需要char ＊類型的時候，可以直接使用CString類型。乍看起來這個好像是個優點，其實實質上還是有很大的缺陷的，特別是可以直接修改char * 而不需要更新類。在轉變為Unicode時這個也碰到很大的麻煩。（CString隨編譯選項可以是Unicode版）相反，QString在內部以unicode存儲string，需要時提供char ＊功能。實際上很少用到char ＊，因為整個Qt的API用文本的方式響應QString參數。QString還附帶許多其他的功能，比如自動分享QString的內容。這是一個非常強大的類，你會喜歡在很多地方用它的。

國際化

使用MFC是可以國際化的，但是需要將每一個字符串放在一個字符串表中，在代碼中到處使用LoadString(IDENTIFIET)，然后轉化這些資源到DLL中，翻譯字符串到所需要的語言，改變圖形界面，然后調用程序使用這個DLL。整個過程是如此的繁瑣，可謂牽一發而動全身，考慮的事情要面面俱到。

使用Qt的時候，只需要將字符串置于函數tr()中，在程序開發中這算是舉手之勞，可以直接在代碼中改變字符串的參考。Qt Linguist是Qt的一個工具，能夠提取所有待翻譯的string并按照友好的界面顯示出來。這個用戶界面非常適合翻譯，使用字典，顯示字符串內容，恰當的unicode顯示，快捷方式沖突檢測，檢測未翻譯的字符串，檢測字符串修改情況，功能齊全。這個軟件可以供沒有任何編程經驗的翻譯者使用。同時該軟件在GPL的版權下發布，可以按照你的需求來修改它。翻譯以后的文檔保存在XML中，適合軟件復用的原則。為軟件增加一種新的語言版本僅僅是用Qt Linguist產生一個新的文件而已。

resources問題

使用MFC，一部分開發過程要依靠“resources”，在很多的案例中開發者必須使用它們。這樣會導致如下的后果：除了Visual Studio，你很難使用其他的工具來完成開發。 資源編輯器僅有有限的功能，比如：通過Dialog編輯器不可能改變所有的屬性，一些屬性可以改變，另一些屬性則不可能改變。

然而Qt并沒有資源的概念，這就解決了以上所提到的問題。Qt提供了一個腳本使得能將其編入你的代碼中。對于界面設計，Qt Designer則創建了可讀的代碼。

發布

在發布基于MFC的軟件時，必須依靠存在于客戶電腦上的MFC。但是這是不安全的，同樣是MFC42.dll，可以基于相同的庫得到3個不同的版本。通常，需要檢查是否擁有正確的MFC42.dll版本，如果不是，就升級它。

Qt則沒有這個風險，因為Qt壓根就沒有“升級整個系統”這個概念。

速度

MFC是專為Windows設計的，而Qt是跨平臺的。所以MFC編寫的程序的運行速度、響應時間都優于Qt。

本文轉載自

PS:相關產品下載請點擊查看>>

Telerik UI聯合慧都科技全場讓利!全線7.5折！點擊查看詳情>>