廣告贊助



ATL、STL、WTL、MFC、GTK、QT、WPF



STL即 Standard Template Library (標准模板庫)
STL是惠普實驗室開發的一系列軟件的統稱。它是由Alexander Stepanov、Meng Lee和David R Musser在惠普實驗室工作時所開發出來的。現在雖說它主要出現在C++中,但在被引入C++之前該技術就已經存在了很長的一段時間。
STL的代碼從廣義上講分為三類:algorithm(算法)、container(容器)和iterator(迭代器),幾乎所有的代碼都采用了模板類和模版函數的方式,這相比於傳統的由函數和類組成的庫來說提供了更好的代碼重用機會。
從根本上說,STL是一些“容器”的集合,這些“容器”有list,vector,set,map等,STL也是算法和其他一些組件的集合。這裡的“容器”和算法的集合指的是世界上很多聰明人很多年的傑作。

STL的目的是標准化組件,這樣你就不用重新開發它們了。你可以僅僅使用這些現成的組件。STL現在是C++的一部分,因此不用額外安裝什麼。它被內建在 你的編譯器之內。因為STL的list是一個簡單的容器,所以我打算從它開始介紹STL如何使用。如果你懂得了這個概念,其他的就都沒有問題了。另外,list容器是相當簡單的,我們會看到這一點。
這篇文章中我們將會看到如何定義和初始化一個list,計算它的元素的數量,從一個list裡查找元素,刪除元素,和一些其他的操作。要作到這些,我們將會討論兩個不同的算法,STL通用算法都是可以操作不止一個容器的,而list的成員函數是list容器專有的操作。
STL容器可以保存對像,內建對像和類對像。它們會安全的保存對像,並定義我們能夠操作的這個對像的接口。放在蛋架上的雞蛋不會滾到桌上。它們很安全。因此,在STL容器中的對像也很安全。我知道這個比喻聽起來很老土,但是它很正確。
STL算法是標准算法,我們可以把它們應用在那些容器中的對像上。這些算法都有很著名的執行特性。它們可以給對像排序,刪除它們,給它們記數,比較,找出特殊的對像,把它們合並到另一個容器中,以及執行其他有用的操作。
STL iterator就像是容器中指向對像的指針。STL的算法使用iterator在容器上進行操作。Iterator設置算法的邊界 ,容器的長度,和其他一些事情。舉個例子,有些iterator僅讓算法讀元素,有一些讓算法寫元素,有一些則兩者都行。 Iterator也決定在容器中處理的方向。
你可以通過調用容器的成員函數begin()來得到一個指向一個容器起始位置的iterator。你可以調用一個容器的 end() 函數來得到過去的最後一個值(就是處理停在那的那個值)。
這就是STL所有的東西,容器、算法、和允許算法工作在容器中的元素上的iterator。 算法以合適、標准的方法操作對像,並可通過iterator得到容器精確的長度。一旦做了這些,它們就在也不會“跑出邊界”。還有一些其他的對這些核心組件類型有功能性增強的組件,例如函數對像。


STL有6大組件:algorithm(算法)、container(容器)、iterator(迭代器)、function object(函數對像)、adaptors(適配器)和allocator(記憶體配置器),其中最主要的是前三個組件。

-----------------------

ATL: Active Template Library (活動模板庫)
可以看一下潘愛民關於《ATL Internals》的書評:
ATL是一個產生C++/COM代碼的框架,就如同C語言是一個產生彙編代碼的框架
ATL又不同於MFC,它完全面向COM組件,其技術路線也不同於MFC,MFC使用的是C++中的繼承、封裝、嵌套等常規技術,而ATL使用了C++中模板、多繼承等高級技術,甚至還用到了STL。所以學習和使用ATL要求我們必須熟悉這些C++高級特性。另一方面,ATL結構完全針對COM中的諸多規範,這就要求使用人員必須非常了解COM規範,才有可能真正把ATL用好
對於COM應用的開發,ATL無疑是首選的工具,與MFC相比,ATL的規模還不算大,但是從上述的介紹我們可以看出,ATL涉及到了COM的方方面面。 實際上,ATL的內容還要多得多,比如OLE DB的支持、MTS的支持等,盡管如此,如果我們有了這本書中的內容為基礎,那麼再去學習這些擴展的內容就會容易得多,結合ATL中實現COM的基本手段 加上這些應用技術的背景知識,我們可以很容易地掌握這些開發技術。
但是如果我們要想熟練掌握甚至精通ATL的話,那麼這只是一個開頭,前面還有漫長的路要走。原因有多方面,一則COM本身異常復雜,不下苦功難窺全貌;二則ATL確實奧妙很多,它體現了C++語法的博大精深;三則ATL還存在很多錯誤,雖然本書作者指出了一些錯誤,但實際的錯誤肯定更多,這就對ATL使用者提出了更高的要求,如果使用過程中不能發現這些錯誤或者避開這些錯誤,那麼用ATL反而會阻礙我們的工作。
雖然ATL比較精深,但是這本書的講解非常通俗易懂,語言比較簡練,條理非常清楚。即使在讀完這本書之後,它仍然可以作為參考書指導我們的開發和學習工作。我想,這就是好書的價值所在吧。


使用ATL能夠快速地開發出高效、簡潔的代碼(EffectiveandSlim code),同時對COM組件的開發提供最大限度的代碼自動生成以及可視化支持。
入口函數為 DllMain (進程內組件)
入口函數為 tWinMain (進程外組件)
入口函數為 CWinApp (ATL支持MFC)
在ATL產生以前,開發COM組件的方法主要有兩種:一是使用COM SDK直接開發COM組件,另一種方式是通過MFC提供的COM支持來實現。
首先ATL的基本目標就是使COM應用開發盡可能地自動化,這個基本目標就決定了ATL只面向COM開發提供支持。
其次,ATL因其采用了特定的基本實現技術,擺脫了大量冗余代碼,使用ATL開發出來的COM應用的代碼簡練高效,即所謂的“Slim Code”。
第三,ATL的各個版本對Microsoft的基於COM的各種新的組件技術如MTS、ASP等都有很好的支持,ATL對新技術的反應速度大大快於MFC。ATL已經成為Microsoft支持COM應用開發的主要開發工具,因此COM技術方面的新進展在很短的時間內都會在ATL中得到反映。這使開發者使用ATL進行COM編程可以得到直接使用COMSDK編程同樣的靈活性和強大的功能。


-----------------------
WTL = Windows Template Library

WTL都算不上什麼Framework,就是利用泛型特性對Win API做了層封裝,設計思路也沒擺脫MFC的影響,實際上用泛型做UI Framework也只能算是一次行為藝術,這個思路下繼續發展就會變得沒法用了,比如 代碼過於復雜,編譯太慢,出錯不好調試等問題難以解決。而且封裝得也不完全,還是隨處可見 HWND HDC之類的東西。用途主要是寫一些很小的程序,或者作為其他UI框架的後端實現部分,比如我寫過一個小框架用來做安裝卸載程序,非常小,其中創建管理窗口部分是用WTL的。

Windows Template Library(WTL)是一個用於Win32研發的物件導向的C++模板函式庫。WTL由Microsoft的員工Nenad Stefanovic創造,起初作為內部使用,之後發行為Visual Studio和Win32 Framework SDK的不支援增益集。它主要被開發作為Microsoft Foundation Classes的輕量化替代品,以微軟ATL函式庫(另一個被應用在創造COM與ActiveX的輕量函式庫)為基礎。

可以說起源於ATL 類庫中關於Window 創建/管理的類。主要原因是用原始的 WIN32 API 編寫漂亮的用戶界面工作量大,繁雜。MFC 雖然提供了一套很好的封裝,但是也不是很容易消化和使用,特別是各個MFC 類之間耦合很緊,要用好 MFC 就要理解很多 MFC 內在的運行機制(有人說 MFC 的封裝是“白盒”封裝,呵呵)。WTL 利用 C++ 模版的高級功能,提供很聯系很松散的“獨立”的類庫,使用起來比較方便,而且代碼體積小,不必為了學習某個類必須學習一大堆相關的類。

-----------------------


MFC是更高級點的Win API封裝,比WTL封裝徹底,很難見到HWND HDC了,也提供了不少實用工具類,比如高級控件,泛型容器,IO訪問,網絡協議等。除此之外,還提供了一些基本框架,比如 Document/View,這就是個MVC的簡化版本,只有MV,但是對於數據的管理,消息的傳遞等又沒有什麼約束,導致Doc/View被用得亂七八糟。尤其是對事件處理的模型,消息映射是功能簡陋,而且容易出錯的方式,唯一優點是性能好。 從VC++ 1.X就有MFC了,那時整個UI界的設計思想都比較落後(除了Apple),MFC又背負了沉重的兼容性包袱,比如vc++ 1.52的MFC程序到了vc2003稍加修改都可以編譯,導致MFC後期沒有什麼發展,就是沿著老的思路完善了些細節,添加了些組件,但是根本性的設計問題沒有改進。

-----------------------

GTK,這個吃了語言的虧,用C寫面向對像實在是痛苦,雖然在思想上比MFC要先進了些,但是寫出來的代碼比MFC要羅嗦很多了。相比MFC,多了Layout的概念,事件處理上有了Signal/slot,雖然用起來很麻煩。wxWidgets,這個基本就是個跨平台的MFC,對各個平台的差異做了抽像,實際上後端大多還是用平台原生的API實現,好多控件都是直接用系統原生的。有wxWidgets for GTK+的版本,後端就是GTK+,wxWidgets就是一層殼。這也是wxWidgets的優點,它編譯出來的程序發行包比較小,性能也不錯。



***************************************************
***************************************************

以上這些就是上世紀90年代的UI Framework技術水平了,至今它們也依然沒有太多進步。下面來談談21世紀的技術。Qt,雖然它也是上世紀90年代出現的,但是它在21世紀有了長足的進步。應該說它的起點就比較高,一開始就定位跨平台,而且不滿足於簡單封裝系統API,而是要自己創造出一套完整的API和框架,甚至要代替系統API,所以不僅僅是做UI,而是涉及到了APP開發所用到的所有東西,包括網絡,數據庫,多媒體,腳本引擎等。signal/slot是Qt發明的,這是事件通知模型裡C++語言的最佳實現了,甚至我都覺得這該寫進C++標准,估計C++委員會的老頑固們是從不寫GUI的。早期的QT也是沒有DirectUI的概念的,每一個QWidget都對應一個原生窗口,從Qt4.4開始,只有頂層QWidget才是原生窗口,而Child Widget是Alien Widget,只是個抽像的圖層不對應原生窗口,這就實現了DirectUI的概念,很多圖形效果也就變得可能了,比如窗口層疊透明效果。在4.8後實現了QPA(Qt Platform Abstraction),這就使移植Qt變得很容易,目前Qt是支持平台最多的框架沒有之一。由於早期授權的問題,Qt對於開源社區不是很友好,導致推廣不太順利,直到它改成了LGPL方式,如果Qt能早點想開了,恐怕就沒有wxWidgets的生存空間了。Qt的缺點也是有的,就是太大,不過可以自己剪裁,我可以把QT庫剪裁到發行包壓縮後2.5MB。


-----------------------

WPF,微軟在Win Form的思路上走到死胡同後,終於痛下決心用正確的方法開發UI庫了。21世紀的UI一定是定義出來的,絕對不能是代碼寫出來的,所以有了XAML這個強大的定義工具,不但可以定義UI布局,還包括圖形動畫效果,消息響應方式等。配合C#這種優秀的語言,更是如虎添翼。但是問題也很明顯,就是過於龐大,不僅開發時要用到龐大的IDE和設計工具,發行的安裝包也十分巨大,所以目前還是很少有人拿他寫通用軟件客戶端的,大多是做企業項目時寫專用客戶端。大概4-5年前吧疼訊曾經用WPF寫了個QQ,但是只實現了基本功能就已經比C++客戶端大好多了,而且運行緩慢,主要是太吃內存,而且那時WPF的優化還不充分。


-----------------------

如果僅在Windows下,追求程序小巧,用WTL,不足的地方自己實現去吧,但是視覺效果就呵呵了。如果可以大一點,還要好看點,那就Qt。如果完全不在乎大小,只要視覺效果華麗,就用WPF,如果把開發工具價格也考慮進來,那麼土豪才會選WPF呢。MFC就是個雞肋了,除非你現有的工程師不會用別的,或者有歷史遺留代碼要保持兼容。

如果要求跨平台,那麼就用Qt


-----------------------


REF:

https://www.zhihu.com/question/23480014/answer/24809080
https://zh.wikipedia.org/wiki/Windows_Template_Library
http://blog.csdn.net/xdrt81y/article/details/17143135
創作者介紹
創作者 天才R 的頭像
天才R

做 個 有 趣 的 人

天才R 發表在 痞客邦 留言(0) 人氣()