cexer

@OwnWaterloo
【boost有自己的苦衷。它需要一個簡短的東西來做占位符。】
你誤會我的意思了。我是同意你的，我的意思是確實應(yīng)該避免使用，因為像 boost,stl 之類的庫很多地使用了這樣的下劃線。

【將_HandlerMapIter改為HandlerMapIter或者HandlerMapIter_真的沒有壞處。
本來就是一個private，庫用戶不可見的名字。屬于Handler，也不會和其他重名。還避免了(可能微乎其微)與_HandlerMapIter宏沖突。】
嗯，明白你的意思。其實這是我的習(xí)慣，外部不可見的都加個下劃線在前頭，沒考慮到與標(biāo)準庫發(fā)生沖突的情況，你想的更細致一點。

@OwnWaterloo
【剛醒…… 一邊吃飯一邊先把不涉及風(fēng)格的東西解釋一下……】
你們那里沒有出太陽？這么大好時光不要拿來睡覺浪費了。回復(fù)完這個，我就出去曬太陽了。

【調(diào)用的是子類的函數(shù)，使用的是父類的數(shù)據(jù)(被切割了)……】
函數(shù)指針和虛函數(shù)的唯一區(qū)別就是函數(shù)指針少個讀表的動作。所以如果說這樣破壞了“不變式”，那么虛函數(shù)也是一樣的。使用子類函數(shù)讀父類數(shù)據(jù)，這種手法是經(jīng)常被用到各種模式中的，這里也不存在切割問題，因為已經(jīng)沒有什么可以切割的。

【語言保留的標(biāo)識符還分了幾種， 統(tǒng)一起來就是以下劃線開始的程序員全都不能使用。】
這只專家們一個很學(xué)究氣的建議，跟“謹慎使用內(nèi)聯(lián)函數(shù)”一樣的警示級別。因為標(biāo)準庫的作者確實使用了一些下劃線的變量，boost 也有很多下劃線開始的東西，像占位符 _1，_2，..._n。為了避免名字沖突確實少用為妙，但用了也不應(yīng)該看作錯誤。

@Loaden
謝謝老鄧！也希望你的框架再進化！

@OwnWaterloo
【強行使用class， 會使得需要定制的時候，就需要定義一個類 —— 其實僅僅需要定制一個函數(shù)就可以了。】
這樣的設(shè)計也是跟框架的整體設(shè)計有關(guān)系，以后寫了消息映射者你再看看。倒是沒考慮過使用函數(shù)來實現(xiàn)消息檢查者，我更喜歡它有對象的感覺一點，OOP語言嘛，而且類是肯定比函數(shù)有大得多的靈活性的。

【有些不需要id,wp,lp的checker該怎么辦呢……需要比id,wp,lp更多參數(shù)的checker又該怎么辦呢……】
之所以不需要再需要新的成員數(shù)據(jù)，是因為消息本身就只有那幾個數(shù)據(jù)。如果需要檢查更復(fù)雜的情況，比如說字符串，這樣的模式也是可以勝任的，以前實現(xiàn)過。在 MessageChecker 當(dāng)中加一個多態(tài)的 Data 成員，它的多態(tài)復(fù)雜度要比 MessageChecker 本身在堆上分配的小得多，目前沒遇到id，wparam，lparam 三個參數(shù)解決不了問題的情況，暫時不會增加這個 Data 成員。

【從msvc和gcc的實現(xiàn)來看，虛指針是切割不掉的，它在父類中。虛表就更不存在切割一說……】
這樣走旁門左道是因為以前確實遇到過虛函數(shù)失效的問題，應(yīng)該不會真是我忘了用指針調(diào)用了吧？更可能是編譯器bug，因為指針調(diào)用虛函數(shù)從小就記得。VC71對于C++標(biāo)準的支持不是很理想，遇到過很多編譯器報“cl.exe 內(nèi)部錯誤”，特別是涉及模板的時候。

【是因為這樣可以多態(tài)調(diào)用，但不能保證子類的不變式……調(diào)用的是子類的函數(shù)，使用的是父類的數(shù)據(jù)(被切割了)……】
什么不變式要變式哦，聽起來好討厭，能抓貓的就是牛老鼠。寫出來的程序編譯通過鏈接成功，客戶能運行它的時候覺得心里爽就行了，所有的規(guī)則應(yīng)該是為這個最終的目的服務(wù)的，而不應(yīng)該為規(guī)則而規(guī)則。

【“for (_HandlerMapIter it = m_map.begin(); it!=m_map.end(); ++it)這個效率是很低的……HandlerMapIter的命名也是不符合c/c++規(guī)范的…… 都被Gof帶壞了……】
我倒是并不覺得它的效率很低，因為只是十多次的循環(huán)，不過也希望看看你有更有效率的方法。命令風(fēng)格是被翻炒了千億次的問題了，使程序員從編碼到設(shè)計都能保持最大的個性，我覺得正是C++的一大特色。就算有人腰上圍一圈炸彈手執(zhí)打火機來逼我改風(fēng)格，我依然視死如歸地覺得自己的命名方式美妙絕倫無以倫比的，堅持風(fēng)格得有血可流有頭可斷發(fā)型不能亂的勇氣啊。所以你就將就著看了。

“規(guī)則，風(fēng)格，效率”，OwnWaterloo兄弟啊，你就是典型的傳說中的學(xué)院派 cpper 。很高興又來占我沙發(fā)，同時很是抱歉，這篇博文可能讓你失望了。但我會再接再勵，希望后續(xù)的文章能引起你的興趣，不負你兩占沙發(fā)的厚望。

@OwnWaterloo

你的這個需求有點像 java 的 AWT 的 添加 listener 的方式
addWindowListener ( new WindowListener(){
　　void windowOpened(){ ...... }
　　void windowClosing(){ ...... }
} );

也有點類似自動化腳本的
onclick = "javascript:{......}"

或者 lua 的
window.onClick = function( arg )
begin
　　--......
end

確實是很誘人的語法。可惜三種 C++ 都不能實現(xiàn)，boost::lamda 生成的函數(shù)對象好像是臨時的吧？也不能這樣保存起來以后再使用。

@OwnWaterloo

你說：“如果在修改wc并注冊之前，已經(jīng)創(chuàng)建了一些窗口呢？
會怎樣？ 也會跟著被修改？ 不會吧……？”

確實不會。Windows 還沒實現(xiàn)那么神奇的功能，而且沒必要。如果需要同時修改已經(jīng)創(chuàng)建的窗口，就只能列舉出來一個個地子類化。

@OwnWaterloo
你說：“超類化？”

隨手找了篇文章：http://hi.baidu.com/combojiang/blog/item/45e968b7b8a510f131add11c.html@OwnWaterloo


你說：“跟是否可以函數(shù)對象沒什么關(guān)系。主要需求是定義這個回調(diào)(或者函數(shù)對象)的地方最好和使用這個回調(diào)的地方比較接近。”

我的意思是，可以定義函數(shù)對象代替函數(shù)來作為回調(diào)。實在是需要純粹的回調(diào)函數(shù)，也可以在外面定義一個公用的模板，然后在內(nèi)部定義一個函數(shù)對象為參數(shù)來具現(xiàn)化這個模板，就獲得了真正的函數(shù)地址。不知這個是否與你的需求有所出入？

@OwnWaterloo

你說：“已經(jīng)注冊過的窗口類，如果要塞context，都需要subclassing。
SetWindowLongPtr( hwnd, GWLP_WNDPROC, insert_context );
然后在insert_context中將context塞進去，SetProp或thunk。
只是GetWindowLongPtr塞不了。”

可以塞的，只是需要超類化（superclassing）之后再塞。子類化(subclassing)在這里不行。但超類化是更需要謹慎使用的東西。


你說：“如何在調(diào)用點上創(chuàng)建這個回調(diào)函數(shù)，而不是在調(diào)用點所在函數(shù)外。“

C++不能創(chuàng)嵌套函數(shù)的，但可以在函數(shù)當(dāng)中創(chuàng)建一個函數(shù)對象。你試試看？

@OwnWaterloo
你說“那這個成員函數(shù)g，就不能在另一個線程中使用。因為table = get_tss_table();是線程相關(guān)的。”
首先用表肯定是可以的，比如說我們一個全局表。針對映射表的操作有三種，一種窗口創(chuàng)建時的插入，一種窗口銷毀時的刪除，還有就是窗口消息來時的查詢。創(chuàng)建和銷毀是在調(diào)用的 GUI 線程當(dāng)中進行的，做不到跨線程的創(chuàng)建和銷毀。而查詢時是在 WNDPROC 中進行的，這個函數(shù)是由系統(tǒng)調(diào)用，也是在 GUI 線程中運行的。既然所有的操作都在同一個 GUI 線程，那何必要用全局表呢，還要加鎖，這不正是 TSS 派上用場的地方嘛。

你說：“GetWindowLongPtr的其他限制”
GetWindowLongPtr 確實有比較大的限制。除了你所說的，對話框，按鈕這類的已經(jīng)注冊過的窗口類，其 cbWndExtra 都已經(jīng)是固定的，要想使用 GetWindowLongPtr 來存取額外數(shù)據(jù)的話，就必須要超類化，這樣的就又麻煩了。所以綜合考慮，SetProp 和 thunk 是最優(yōu)選擇。

你說：“總之…… win32 gui是很浩瀚的事情…………“
當(dāng)然是的，不浩翰就沒有辟波斬浪的快感嘛。OwnWaterloo 晚上兩點還堅持在前線？深更半夜的，都在研究些什么高深課題呢？多好的睡覺時間啊，晚上睡得香，白天不嗑睡，早起早睡效率才更高！

@OwnWaterloo
你說：“性感誘人吧？ 所以我極力推薦這妞……
也正因為誤解很嚴重……
所以用戶代碼訪問 [0, length ) 的幾率還真不大……”

確實非常性感誘惑人，我們不要宣揚了，好東西我們兩知道就好了，哈哈！MSDN真是有點猥瑣。。。實現(xiàn)這么好個功能，卻不知道大書特書，讓那 GWL_USERDATA 忽悠了不知道多少程序員。OwnWaterloo 兄弟，該睡覺了，身體是革命的本錢啊，再聊。

@OwnWaterloo
你說：“我一直都在強調(diào)……
GetWindowLongPtr, GWL_USERDATA是普遍被誤解了的……”

哈哈，原來如此。看來我對 GetWindowLongPtr 真是有深深的誤解！和你一番討論挺有收獲的，這樣看來我得再多權(quán)衡一下了！這樣的 GetWindowLongPtr 是一個誘人的選擇。看來不看書，只聽道聽途說來的東西真是不行的。可以回頭去睡覺了，多謝了！

@OwnWaterloo
你說的：“
oid f( CWnd* w)
{
CWnd* d = w->GetItem( ... );
d->GetWindowTitle( ... );
}
具體是不是叫這個名字不記得了。
由一個窗口得到上面的控件的窗口，然后取一下標(biāo)題。
如果w來自另一個線程 …… 等著程序掛吧……
d是一個指針，有主動釋放嗎？
mfc的消息循環(huán)還會在odle時清除這種"臨時對象"的指針。
就為了滿足它的table機制，需要在動態(tài)內(nèi)存中創(chuàng)建對象，并使用類似gc的機制去清理……
mfc的大、慢就是這么一點一點的積累出來的。
table這種方式絕不可取……
”

你說的這個是 MFC 的實現(xiàn)嘛，MFC 還在系統(tǒng)中加了鉤子呢。它的這個指針之所以有諸如線程的限制，也是因為實現(xiàn)的功能太雜。我們的 TSS 表可是壓根沒想過要實現(xiàn)這么個“臨時指針”的功能。關(guān)于跨線程調(diào)用，應(yīng)該是 API 是怎么樣，跨線程調(diào)用成員函數(shù)也應(yīng)該能干啥。TSS 表只是消息到窗口類當(dāng)中很小的一步，不該影響到窗口類本身的工作。所以函數(shù)調(diào)用跟 TSS 表一點關(guān)系都沒有的，如果一個函數(shù)調(diào)用因為 TSS 表而崩潰，那就是有問題的實現(xiàn)了。以前用過這種方式實現(xiàn)的，正是考慮到多線程才使用 TSS。

@OwnWaterloo
我可沒說不考慮效率哈。別說C++，就算用石頭寫程序，都得考慮效率的。只是效率不是影響一切的標(biāo)準，特別是當(dāng)效率的差別微乎其微的時候。我不是不考慮效率，而是覺得用 thunk 實現(xiàn) GUI 框架的效率不一定就能高多少，因為真正吊車尾的是消息隊列， SetProp 和 thunk 這點微末的時間，相對系統(tǒng)得到事件，生成消息，翻譯消息，發(fā)送消息，排隊消息的這一大堆的內(nèi)部操作的時間來說，短得不值一提。GUI 線程只是用來跑 GUI 的，不能用 GUI 線程來完成分步式計算啊。

用 GetWindowLongPtr 來作為實現(xiàn)框架確實也很簡單，效率也最高。但因為GWL_USERDATAR 的眾所周知而又獨一無二，這個問題是很嚴重的，而且很明顯，OwnWaterloo兄啊，何苦這么執(zhí)著地為它辯護。。。。要是在廣告中說道，“此 GUI 框架物美價廉童叟無欺，但請不要使用 GWL_USERDATA 因為本框架要使用”，怎么賣得出去啊。

三種方式當(dāng)中 thunk 和 SetProp 確實是前者優(yōu)一點，我個人放棄效率而選擇標(biāo)準一點的實現(xiàn)。至于 GetWindowLongPtr ，現(xiàn)在你就算用左輪手槍指著我的腦袋，我也還是堅持不能用的哈 。

@OwnWaterloo
就像你把火箭的點火系統(tǒng)裝到拖拉機上，轟轟烈烈地點燃了拖拉機，它還是不能以宇宙第一速度脫離地球獲得自由一樣。Windows 系統(tǒng)維護消息隊列的時間遠遠多于消息到窗口那一彈指一揮間，我們再努力地擠時間出來也只是尋求心理上的安慰。所以在寫 GUI 框架時我盡量避免的是空間消耗而不是時間。

不過最佩服C++程序員們的一大優(yōu)點就是，就算只有一點效率也是要打破腦袋擠出來的，有總比沒有好嘛。你們討論的我都認真看到，在效率和安全上 thunk 確實是很明顯的最佳選擇，我在考慮以后用這個了。在利益的誘惑下，心里的負罪感是可以克服的！

還是不敢選 GetWinowLongPtr 。它的好用是世人皆知的，就像一個大美女，人人都想染指一把，很難說在哪個月黑風(fēng)高的晚上，哪個不愛看文檔的程序員就忍不住用了它，于是崩潰藍屏，整個世界清靜了。。。這樣的事一定會發(fā)生的，因為不愛看文檔的人太多了。

SetProp 雖然也有危險，但是那概率小得多。世上的 Windows 程序員有多少，這些 Windows 程序員當(dāng)中寫 GUI 的又有多少，寫 GUI 的程序員們直接用 API 寫的又有多少，直接用 API 寫的用到 SetProp 的又有多少，用到 SetProp 偏偏又用到和我一樣參數(shù)的又有多少呢。我感覺遇到這樣的概率比走路時被不明飛行物砸中的概率還要小。

當(dāng)然作為一個庫的作者，不能把完全安全性交給概率去解決。不像 GetWindowLongPtr 你只能眼睜等著崩潰，用 SetProp 為了增大安全性可以有很多手段。可以用一個 GUID 來 SetProp( guid .... ) ，可以用圓周率3.14159265。。。。，甚至可以用對女朋友的愛情宣言全文，愛是獨一無二的嘛！

MFC的窗口指針可以在線程間傳遞，只是除了 SendMessage 之外能干的事不多。這跟那個 TSS 表沒多大關(guān)系，GUI 很多 API 本身就是不能跨線程。真正不能在線程間傳遞的是 TSS 表本身，我們用 TSS 的目的就是避免線程間的牽扯，當(dāng)然是不會在線程間傳來傳去的，而且這個表對 GUI 框架的客戶而言是看不到的，想傳也傳不了。TSS 映射表的速度也不如想像中的慢，一個再巨型的 GUI 軟件，能有多少窗口可供映射的呢。

這些方法我都用過。權(quán)衡起來，還是覺得 SetProp 是最簡單好用的一個，有興趣的同志可以測試一下在 SetProp 和 thunk 的實現(xiàn)效率差別有多大。我個人覺得在消息隊列吊車尾的情況下，差別不大。

@Loaden
thunk 完成的功能只是消息從系統(tǒng)到窗口類的很小一步，也是最需要完成的第一步。在這一步上我嘗試過很多方法，包括這種 thunk 技術(shù)，甚至還用過TLS做映射。我目前用的方法很簡單就是 SetProp，GetProp 兩個函數(shù)，有點重劍換木劍的感覺。效率上肯定沒有 thunk 的直接調(diào)用高，但是心里更踏實一點，在內(nèi)存當(dāng)中寫二進制代碼總有在犯罪的感覺。

“過早的優(yōu)化是一切罪惡的根源”。基于這一步只是整個GUI框架當(dāng)中是很微小的一步，幾乎不影響框架設(shè)計，可以先把框架搭好，再來從安全，效率，可移值性各個方面進行考慮。反正不要選擇 GetWindowLong ，GWLP_USERDATA 那一套，如果發(fā)布出去后客戶也使用這個東西就一切全完了，“過時的悲觀毫無益處”。

你的消息封裝看起來很舒服，肯定在 GUI 框架上也是下過很多功夫，喜歡重復(fù)制造車輪的的同志，我對這個興趣也比較大，希望以后能多與你多交流互相學(xué)習(xí)，革命路上并肩攜手一同進步!

@暗涌
嗯呵呵

@XML
那個代碼找不到了，不過實現(xiàn)還記得，以后會寫一下實現(xiàn)。

@null
讀書千遍其義自現(xiàn)啊，最主要是悶著看代碼。
從示例代碼，最高層開始往底層追溯

@OwnWaterloo
模板有一大優(yōu)勢就是，不必在意類型是否已經(jīng)存在，就能夠任意調(diào)用它的任意成員。這是用虛函數(shù)也達不到的，因為虛函數(shù)也至少需要提供接口聲明。
ATL這種方式，可以在不知道子類為何物的情況下調(diào)用它重寫或者覆蓋的成員。有時候可以完成用虛函數(shù)也無法達到的效果。
你試試不用虛函數(shù)，不用ATL的這種編譯時的多態(tài)手法，在不知道子類為何物的情況下，在基類當(dāng)中調(diào)用子類的方法試試？

@OwnWaterloo
我的理解是所謂的ATL-Style，其實是用模板在編譯期手工模擬的一種多態(tài)，ATL 的實現(xiàn)當(dāng)中大量地使用了這種方式，目的就是為了輕量級，幾乎沒用過虛函數(shù)。
我覺得這種手法的作用不僅僅限于此，因為可以結(jié)合其它的編譯期技術(shù)，實現(xiàn)很多虛函數(shù)難以達到的功能，我實現(xiàn) GUI 框架的時候也用到很多這種東西，以后的說明中應(yīng)該會遇到。

@OwnWaterloo
他少打一個字母！done

@陳梓瀚(vczh)
你說“我跟OwnWaterloo就借著你的地盤版聊了哈”

絕沒問題，歡迎有自己思考的同志來此版聊，如果能切緊GUI框架的主題就感謝了哈，你們的討論能使我的博文增色不少。聊完不要走，此處管飯。

@俠客西風(fēng)
呵呵謝謝你能喜歡，其實我對技術(shù)的探求不是很深，只是迷戀于一些更簡單更表面的東西。做技術(shù)的人其實這樣不是很好。
你就不要準備了，直接把我加進去吧。但我不知道怎么加友情鏈接，在后臺加過好像沒成功。
很高興認識你！

@矩陣操作
謝謝，很高興又認識志同道合的朋友。以后請多指教！

@OwnWaterloo
@陳梓瀚(vczh)
討論了那么多，突然發(fā)現(xiàn)怎么兩位同志的觀點都扭轉(zhuǎn)了？
“C++中實現(xiàn)屬性”這個問題也是討論過千百遍的了，而且注定是誰都無法說服誰的問題，因為它不純粹是一個技術(shù)問題。很大程序上和性格喜歡相關(guān)。就好像實用主義點的程序員，肯定覺得這樣費盡力氣去模仿不值得，但藝術(shù)氣質(zhì)一點的程序員，覺得屬性的語法看起來很漂亮。然后各自用自己的偏好去說服對方，肯定不能成功。
我個人的觀點是，有總比沒有好。存在即合理，要不然怎么會那么多的語言提供語言級的屬性支持了。C++當(dāng)中比這個急迫要解決的問題還很多，但可以預(yù)見，屬性這東西在未來的某個C++標(biāo)準當(dāng)中一定會出現(xiàn)的，它確實有著不可磨滅的價值。

但你們的討論里各自的觀點都很有道理，里面包含的有技術(shù)含量的思考很多，我看過也很有收獲。所以請你們在友好和諧的氣氛當(dāng)中繼續(xù)嘗試說服對方吧，無論是什么樣的討論都是思想的碰撞，也是學(xué)習(xí)的很好的方式。

@OwnWaterloo
謝謝你分享你的思考，真的很有創(chuàng)意。建議你可以把你的思考寫到你的博客里，讓更多的人看到。

@陳梓瀚(vczh)
高效的，不會制造麻煩的東西，也是從不高效的，會制造麻煩的東西進化來的。所以我覺得只要在思考都是有價值的。

@空明流轉(zhuǎn)
好的，是這樣的，《2012》說的是地球毀滅的故事，好了我說完了。
哈哈！

@OwnWaterloo
你說“我想到一個幾乎沒有消耗的方案……我再完善一下……”
加油，出來了別忘了寫出來大家分享。

@OwnWaterloo
你說“我去看了看Imperfect C++。因為是英文的，以前只看了一部分就停了……我覺得前面都寫得不錯，ABI、mangling這些問題確實是很困擾……我繼續(xù)去看書中怎么實現(xiàn)的……”
在C++里面屬性只是看起來很美的東西，其實用性和想像的有差距。你說得對，用方法能實現(xiàn)所有的功能，所以我的GUI框架已經(jīng)去掉了屬性支持。

你說“我以前了解的實現(xiàn)方式，每一個proxy至少得帶一個指針……這消耗還是蠻嚴重的……”
不一定得帶指針的。比如《C++ Imperfect》里實現(xiàn)的屬性是不需要帶指針的，但它不被C++標(biāo)準支持，應(yīng)用有限制。我也實現(xiàn)了不需要帶指針的屬性，同時也是跟C++標(biāo)準相容的，以后會說一下這個實現(xiàn)。

@OwnWaterloo
你說“沒有完整的，就是你blog上發(fā)的一些片段……”
我找找看，找到了也給你一分。那些片段隱藏了實現(xiàn)的，看不出什么有價值的東西。

@WXX
你說“如果單就消息的派發(fā)，那么一個gui框架可以很容易實現(xiàn)，但是要很好的管理窗口之間的關(guān)系，很好的處理鍵盤加速鍵，鼠標(biāo)等這些交互就麻煩了，考慮消息的過濾等。”
各有難處，但我覺得后者更容易一點，以前我也都做過一些。我覺得好的框架應(yīng)該是在所有東西之前的。先有骨架，然后再說高矮胖瘦。長得是否高大健壯，陽光帥氣，就先看骨架如何了。

@OwnWaterloo
你說“哦 原來是property模擬。”
嗯就是這樣的。

你說“這個代理對象也是要占空間的吧？”
理論上來說不要占空間的，但實際是占用一個字節(jié)的。因為C++標(biāo)準規(guī)定不允許存在0空間占用的成員變量，因為那會造成 &object.member1，&object.memeber2 兩個地址完全相同的情況。

@OwnWaterloo
你說的“接下來，框架將message 分派到onXXX之后，客戶再將onXXX轉(zhuǎn)發(fā)(forwarding)自己的handler這個過程，我相信是可以編譯時確定的。
——因為我看過你以前的一些實現(xiàn)~_~”

你說的這個是以前另一個版本的框架了，跟這個完全不一樣了哦。你看那份代碼，它的消息映射是編譯期自動進行的，映射者，檢查者，分解者三個角色都是由一個東西全部完成的。我將寫的這個版本不一樣，是完全分離的實現(xiàn)，沒有那種編譯期映射的功能，但運行時映射可以獲得更大的擴展性。

可惜啊，以前那個版本的框架代碼我已經(jīng)找不到了。你那里有？

你說的“以我很好奇window是如何零成本完成映射與轉(zhuǎn)發(fā)，并且是一個空對象的。映射肯定需要在某個地方做，可能不是window。運行時可更改轉(zhuǎn)發(fā)目的地而不使用數(shù)據(jù)， 好像…… 太不可思議了……”

看來你有點誤會我的意思了，肯定內(nèi)存當(dāng)中是有一個 std:map 之類的映射數(shù)據(jù)存在的。我說的0成本指的是 window.onCreated 這個成員的實現(xiàn)。

@OwnWaterloo
這個消息映射者的實現(xiàn)沒有數(shù)據(jù)成員，沒有虛函數(shù)存在，它其實就是一個調(diào)用，所以它也是有時間成本的。是的，所以我說是接近0成本，而不是真正的0成本。畢竟世界上沒有那樣傳說的員工。但如果好的編譯期可以輕松優(yōu)化掉這個小小調(diào)用。

你說不可思議，那倒沒到那個境界哈。你可以看看《Imperfect C++》當(dāng)中的method_property的實現(xiàn)，跟那個很類似，不過他的實現(xiàn)不符合C++標(biāo)準，應(yīng)范圍有限。

用這種消息映射者的方式，我也實現(xiàn)了值主義的屬性，比如：
window.size = Size( 100,100 );
Size size = window.size;

從理論上來說，也接近0成本的。

@OwnWaterloo
謝謝沙發(fā)，后面會詳細說說這個消息映射者的實現(xiàn)

@stidio
這個設(shè)計是設(shè)計給不跨線程的應(yīng)用的，主要考慮在這種應(yīng)用下，如果線程太多，都去查詢同一個全局的東西，大多數(shù)線程都一直處于等待資源的狀態(tài)，比較浪費CPU時間。
這是在公司時寫的哈，出來后倒沒寫了，感覺是人越來越懶了，寫程序越來越?jīng)]激情

以前也研究過逆向，現(xiàn)在想來還真是有精力
整天在黑漆漆的反匯編里轉(zhuǎn)
還是C++的世界光明啊
http://www.pediy.com/bbshtml/bbs8/pediy8-266.htm
http://www.pediy.com/bbshtml/bbs8/pediy8-260.htm

我覺得這種有點奇巧淫技的意思，不過調(diào)起B(yǎng)UG來真方便。多謝！

@LOGOS
多謝了，我也研究研究。

哪里有下載的源碼

多重繼承的時候，使用C風(fēng)格的轉(zhuǎn)換，可能會出亂子。

well done!

template<int i>
struct sum
{
enum{ result=sum<i-1>::result }
}

template<>
struct sum<1>
{
enum {result = 1 };
}

result = sum<n>::result;

@陳梓瀚(vczh)
是的，那東西還要再修改一下。

鑒于CPPBLOG上批判者多于探討者，炫耀者多于分享者，陳同學(xué)分享代碼是一個不容易的決定，謝謝并支持！！

我那個消息機制我自己已經(jīng)放棄了，不過還是愿意與你探討探討。加我的QQ41086722

@proguru
最近就會寫的。

@陳梓瀚(vczh)
不過如果你不接受類成員指針的話，那么你還是接受interface吧。僅僅接受一般函數(shù)會喪失很多能力的。

我寫這個日志的主題在于實現(xiàn)一個通用的消息映射的數(shù)據(jù)結(jié)構(gòu)，至于消息處理函數(shù)是是成員函數(shù)或自由函數(shù)，不在討論范圍內(nèi)，并且那個很簡單，也不用單獨寫篇日志。

@陳梓瀚(vczh)
現(xiàn)在只是封裝映射的前半部分，下一篇會封裝消息處理函數(shù)的類型。

@LOGOS
為什么說用一個for是不行的呢？這兒只是個示范。不一定非得用map。