huaxiazhihuo

    請(qǐng)容許先發(fā)一句牢騷，“這萬(wàn)惡的成員函數(shù)指針的丑陋語(yǔ)法！”，C中的函數(shù)指針的語(yǔ)法已經(jīng)夠難看的了，但相比之下，成員函數(shù)指針卻更加不堪入目，使用上又很不方便，很不人性化，簡(jiǎn)直是只能行走寸步。只可惜，函數(shù)指針的作用實(shí)在太大了，忽視不得。
    大家都知道，函數(shù)指針（或又叫回調(diào)函數(shù)）是上層模塊和底層模塊進(jìn)行通信的最佳手段，上層通過(guò)提供函數(shù)指針給底層，以使得底層在適當(dāng)?shù)臅r(shí)候，可以調(diào)用執(zhí)行上層的代碼，C庫(kù)中的qsort足以說(shuō)明這種使用，qsort在排序時(shí)，不知道如何比較兩個(gè)數(shù)組元素的大小，必須通過(guò)上層提供的大小比較函數(shù)來(lái)進(jìn)行比較。此外，操作系統(tǒng)提供的API中，有多少地方使用上了回調(diào)函數(shù)。假如沒(méi)有函數(shù)指針，這簡(jiǎn)直沒(méi)法想像，日子沒(méi)法過(guò)了。函數(shù)指針是實(shí)現(xiàn)模塊分層的不二法門，當(dāng)然接口也可以，但是，用戶代碼必須繼承或者實(shí)現(xiàn)底層硬性規(guī)定無(wú)理取鬧的虛函數(shù)，本來(lái)很輕量級(jí)的POD，再也不輕快了，實(shí)在頗不方便，不，簡(jiǎn)直很有點(diǎn)惡心。說(shuō)來(lái)說(shuō)去，還是函數(shù)指針好。
    既然，C中的回調(diào)函數(shù)這么重要，那么，可想而知，進(jìn)入C++中，整個(gè)世界到處都是CLASS，將回調(diào)函數(shù)這個(gè)概念推廣到CLASS上，也即是成員函數(shù)指針，將是多么迫切的事情。理論上，可以將成員函數(shù)指針視為函數(shù)指針的語(yǔ)法糖，只要規(guī)定函數(shù)指針的第一個(gè)參數(shù)為void* pThis，然后在函數(shù)指針的實(shí)現(xiàn)函數(shù)中，進(jìn)行類型轉(zhuǎn)換也能滿足使用，在很長(zhǎng)的一段時(shí)間里，因?yàn)檫@種方式的簡(jiǎn)單清晰，一直都用這種方式代替成員函數(shù)指針。但是，一遍又一遍地被迫編寫重復(fù)代碼，特別是枯燥的類型轉(zhuǎn)換，任何人都無(wú)法忍受。因此，決定直面這個(gè)問(wèn)題。
    理論上，成員函數(shù)和普通函數(shù)一樣，在內(nèi)存中，都有自己的位置，只要有了地址信息，就可以通過(guò)指針來(lái)獲取，保存起來(lái)，然后在未來(lái)的某個(gè)地方，通過(guò)這個(gè)指針來(lái)執(zhí)行函數(shù)中的代碼。差別之處，在于，調(diào)用成員函數(shù)前，要先將this推入ecx中，很久之前，成員函數(shù)指針確實(shí)和普通函數(shù)指針一樣簡(jiǎn)單，只是后來(lái)，虛函數(shù)和多繼承出現(xiàn)之后，簡(jiǎn)單的指針信息再也承載不了成員函數(shù)的重量，從此之后，.......（忽略，請(qǐng)大家自行BAIDU）。總之，C++中，成員函數(shù)指針并非指針類型，理所當(dāng)然，也就不支持指針的大多數(shù)操作，比如，賦值NULL，或者類型轉(zhuǎn)換。因此，所有能夠讓函數(shù)指針大放異彩的種種手段，在這里，都用不上了，原本在C中光芒四射的好東西，到了C++中，竟然黯然失色，所有本該讓函數(shù)指針大顯身手的地方，大家都繞道而行。
    逼急了，也有嘗試突破，MFC的僅僅作了有限爭(zhēng)取的手段（為了這一點(diǎn)點(diǎn)好處，MFC可不知作了多大的努力），居然成為其消息映射的基石。但是，據(jù)說(shuō)，MFC的成員函數(shù)指針的設(shè)計(jì)也非出于自愿，而是因?yàn)橄⑻啵瑢?shí)在沒(méi)法整成虛函數(shù)來(lái)處理，每個(gè)窗口類背負(fù)成千上萬(wàn)個(gè)函數(shù)的虛函數(shù)表，可不是省油的燈。為了努力地支持虛函數(shù)和多繼承，C++的編譯器不惜在成員函數(shù)指針的使用上設(shè)下種種阻攔，令人又氣又恨。而更加令人不解的是，C++橫行天下十幾年，函數(shù)指針?biāo)坪蹰L(zhǎng)期得不到重視，大師們都在面向?qū)ο笊咸剿鳎芏啾驹摮蓡T函數(shù)指針發(fā)光發(fā)熱的地方，幾乎都退位給虛函數(shù)了，并美其名曰策略模式又或者是其他的什么模式，不過(guò)是換了一套更加難看的馬甲，卻又那么好聽(tīng)的名字，不，不好聽(tīng)，只要聽(tīng)到模式兩字，就令人大倒胃口。所有大用特用模式的代碼，如果用非模式來(lái)實(shí)現(xiàn)，其代碼量將少掉很多，而且還更具擴(kuò)展性，這是真的。先透露一下，正在構(gòu)思一文章，將深度介紹模式，專注于WHY，并且類比現(xiàn)實(shí)，兼扯上WINDOWS、COM和MFC對(duì)模式的應(yīng)用，說(shuō)句良心話，如果只用接口來(lái)做設(shè)計(jì)，模式絕對(duì)是好東西。只可惜，接口其實(shí)是SB。寫底層代碼，如果要求用戶必須實(shí)現(xiàn)某些接口，又或者是繼承某些類，改寫虛函數(shù)，這種侵入式的設(shè)計(jì)，實(shí)在無(wú)理取鬧之至。
    后來(lái)，大伙兒也終于開(kāi)始重視成員函數(shù)指針，特別是C#的委托出現(xiàn)之后，網(wǎng)絡(luò)上更是充斥著各種成員函數(shù)指針的版本代碼，都可以很好地完成任務(wù)。特別是TR1又或者是BOOST中的function，功能相當(dāng)?shù)膹?qiáng)悍得令人非大吃一驚不可。只可惜，大多數(shù)情況下，用戶只想填飽肚子而已，但是BOOST或者其他的類庫(kù)卻硬要來(lái)一桌滿漢全席，這也罷了，但是，它還要用戶額外買單，并且還真不低呢，這就很讓人受不了啦。其實(shí)，一般情況下，我們的要求不會(huì)太過(guò)分，僅僅想要針對(duì)普通的成員函數(shù)指針進(jìn)行回調(diào)，它卻為此在其內(nèi)部new一個(gè)內(nèi)部類出來(lái)，假如大規(guī)模使用，后果將不堪設(shè)想，其實(shí)也沒(méi)那么嚴(yán)重，完成是C++迷們的強(qiáng)迫癥。
    但是，說(shuō)真的，實(shí)在希望很精簡(jiǎn)，不要生成不必要的虛函數(shù)表，不要模板生成不必要的函數(shù)（沒(méi)辦法內(nèi)聯(lián)，有函數(shù)地址的那一種），只要求它如同對(duì)待C中的函數(shù)指針一樣，參數(shù)入棧和一個(gè)簡(jiǎn)單的函數(shù)調(diào)用的指令，外加將this推入ecx即可，就好像直接調(diào)用成員函數(shù)那樣就好了。好了，貢獻(xiàn)上代碼了，史上最輕量級(jí)，精簡(jiǎn)無(wú)比的成員函數(shù)指針，功能也最弱了。對(duì)不起，代碼并不完整，實(shí)際的代碼，用上了宏，所謂的宏的圖靈完備。在下很懶，一向只介紹想法而已，只于具體的實(shí)現(xiàn)細(xì)節(jié)以及語(yǔ)法考究，竊以為，每個(gè)C++迷們應(yīng)該完全能夠勝任。俗話說(shuō)，高手只要求創(chuàng)意就行了，本文詳細(xì)介紹算法并給出代碼，已經(jīng)落了下乘。
    這個(gè)實(shí)現(xiàn)，不考慮多繼承，忽略了虛函數(shù)，也不支持非成員函數(shù)（也可以用上，只是，要多做一點(diǎn)點(diǎn)手腳，以下將給出示例，而且，普通函數(shù)指針已經(jīng)完全可以勝任），只集中火力專注于普通成員函數(shù)，畢竟，在下的運(yùn)用中，它占上了95%以上，所以才能如此的高效。單一職責(zé)啊！
    此外，本文參考了《成員函數(shù)指針與高性能的C++委托》、《劉未鵬的BOOST源碼解析》、《C++設(shè)計(jì)新思維》，請(qǐng)自行GOOGLE。