由於業餘時間相對比較少，並且接下來要出差（大約十天左右），看樣子winxcn.com短期內不能出來。為了winx的文件不至於遙遙無期，我決定還是現在開始在blog上**winx的核心文件。或許對於這些文件而言，blog不是乙個很好的載體，因為blog更關注的是社會性，強調的是參與，而體系性較差。
這是開篇第一篇。你可能覺得驚奇——不是要講winx嗎？怎麼，講atl來著？勿須奇怪，winx是基於atl/wtl的，所以，在講winx的原理之前，先要了解atl的基本概念，它們一定程度上是相通的。
atl/wtl的介面開發，網上的教程還是少了點。相信大家都知道《mfc程式設計師的wtl開發指南》，這的確是一套難得的好教材。作為winx的入門篇，我們這一篇是回顧《mfc程式設計師的wtl開發指南》第一篇：「
atl介面類
」（注：為了不至於
重複製造輪子
，我這裡不再贅述該文章已經敘述較為詳細的一些技術細節）。
接觸atl/wtl久了，類似下面這樣的**你一定見得多了：
class myclass : baseclasst
;
把派生類myclass，作為模版引數傳遞給基類baseclasst，這種寫法多多少少顯得有點古怪。但這是合法的。之所以要這樣，是因為我們要實現「編譯期的晚繫結」（
atl介面類
中把它稱為「編譯期間的虛函式呼叫機制」，這是不太準確的說法）。
基於虛函式技術的「執行期（runtime）的晚繫結」大家都已經很熟悉了，這也就是oop中所謂的「多型」。而基於模板技術，所依賴的並非vtable，而是型別不確定型（型別晚繫結），來達到「編譯期的晚繫結」。這也就是所謂的「泛型」。
選擇「多型（虛函式技術）」，還是選擇「泛型（模板技術）」？
模板的好處是「零開銷」——即額外的時間、空間開銷均為零。而虛函式技術在時間上多了一次間接呼叫（由vptr找到vtable中相應的函式位址），並導致inline失效（無法展開）；在空間上每個類物件多了4位元組（這裡假設是32bit系統）的vptr，全域性多了乙個vtable（大小與該類的虛函式個數有關）。
虛函式的好處是「可定義二進位制規範」，從而建立語言無關的呼叫約定。這就是com（元件物件模型）技術關注的內容。進一步來說，虛函式技術比較適合應用於大型程式中的模組劃分，用以描述元件間呼叫契約——inte***ce（介面）。
我並不是模板技術的推崇者。應當認識到，模板與虛函式技術一樣，只適合有限的場合。winx中，訊息分派機制使用了模板，是因為它是最適合的人選。
sting在此：
很高興你提出這個問題。看來你對c++了解很深。我也很不滿意，c++沒有二進位制規範。
其實你說得沒錯，從理論上來說虛表沒有二進位制規範，這種標準是工業上的標準。gcc大概在3.0版本（記不太清楚了）以前，其虛表就不符合com規範，後來迫於無奈修改了。這對gcc影響甚深，因為這意味著gcc3.0以前版本編譯出來的so/dll不能與高版本的gcc編譯的so/dll之間相互進行呼叫。
ATL介面類 兼談多型與泛型
由於業餘時間相對比較少，並且接下來要出差 大約十天左右 看樣子winxcn.com短期內不能出來。為了winx的文件不至於遙遙無期，我決定還是現在開始在blog上 winx的核心文件。或許對於這些文件而言，blog不是乙個很好的載體，因為blog更關注的是社會性，強調的是參與，而體系性較差。這是開篇...
ATL介面類 兼談多型與泛型
由於業餘時間相對比較少，並且接下來要出差 大約十天左右 看樣子winxcn.com短期內不能出來。為了winx的文件不至於遙遙無期，我決定還是現在開始在blog上 winx的核心文件。或許對於這些文件而言，blog不是乙個很好的載體，因為blog更關注的是社會性，強調的是參與，而體系性較差。這是開篇...
泛型類，泛型方法，泛型介面
泛型，就是一種不確定的資料型別。如果在類後面加上 這個類就變成了泛型類。這個 t可以使用任意的字母代替。表示定義了一種不確定的資料型別，這種不確定的資料型別必須在使用這個類 比如建立物件 的時候才能確定下來。如果希望縮小泛型的範圍，延後泛型的確定時間，讓泛型在呼叫方法的時候確定，那麼我們可以使用泛型...