C++委托和消息反饋模板怎么實現(xiàn)

本篇內(nèi)容介紹了“C++委托和消息反饋模板怎么實現(xiàn)”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

繼承+多態(tài)

乍一看是理所當(dāng)然的選擇，庫中的類把響應(yīng)處理函數(shù)設(shè)置為虛函數(shù)，客戶程序可以繼承這個類并且重載響應(yīng)函數(shù)。以某個Socket類為例，可以提供一個OnRecv函數(shù)用來響應(yīng)網(wǎng)絡(luò)數(shù)據(jù)包到達的處理。客戶程序只需要重載OnRecv并進行自己的處理就可以了。

struct Socket { // base class  virtual void OnRecv();  };  stuct MySocket { // your event-handle class  virtual void OnRecv() { /* do sth here ... */ }  }

疑問：很多時候這樣做實在很煩，特別是做小程序的時候，或者需要快速做原型的時候，一眼望去小小的程序一上來就繼承了一大堆東西，頗為不爽。只是想著能省事一點，希望能像那些腳本語言一樣快速綁定消息響應(yīng)，而不是以繼承開始工作——我已經(jīng)害怕看到長長的類繼承樹了，很多時候根本不必要繼承整個類;又或者某些類只提供一個接口而不是具體的類又或者需要多重繼承，處理都有一定麻煩;最麻煩的莫過于有時候需要改變響應(yīng)處理，難道繼承好幾個下來么——這么多虛表也是浪費啊。

點評：為了使用Socket就必須繼承Socket，這可以說是Socket的設(shè)計的問題。如果需要實現(xiàn)類似的功能的話，可以寫成如下，雖然和繼承 Socket 沒有多少本質(zhì)的差別，不過確實把消息處理類和Socket的實現(xiàn)扯開了。

struct SocketEventHandler {  virtual void OnRecv() { /* ... */ }  virtual void OnSend() { /* ... */ }  };  struct Socket {  void set_handler( SocketEventHandler* h ) { handler_ = h; }  private:  SocketEventHandler* handler_;  };  struct MyHandler : SocketEventHandler {  void OnRecv() { ... }  };  Socket s;  MyHandler h;  s.set_handler( &h );

丟開繼承，我們有沒有一種簡單明確的表達方法呢?我不禁想起了c時代的回調(diào)函數(shù)……

回調(diào)函數(shù)(CallBack)

非常簡單，就是一個函數(shù)指針。剛才的OnRecv可以寫成這樣

struct Socket {  void OnRecv() { if(OnRecvHandle!=NULL) OnRecvHandle(); }  void (*OnRecvHandle) ();  };

客戶程序只需要編寫一個MyOnRecv函數(shù)，并且賦值給OnRecvHandle就可以了

void MyOnRecv(); // your event-handle function  Socket foo;  foo.OnRecvHandle = MyOnRecv;

疑問：非常簡單，不需要繼承類就可以處理，而且隨時可以替換不同的處理函數(shù)。其實多態(tài)的本質(zhì)也是函數(shù)指針，只不過多態(tài)是用vtable統(tǒng)一管理函數(shù)指針。回調(diào)函數(shù)要特別注意函數(shù)指針是否為空的問題，因此***外面在包裝一層判斷過程，回調(diào)函數(shù)***問題在于類型不安全。

委托(Delegation)

委托是什么呢?委托最本質(zhì)的是提供一種類型安全的動態(tài)消息響應(yīng)轉(zhuǎn)移機制。

以前，我對委托一無所知，我覺得無非就是一個類型安全的智能指針，而所謂的Multi-Cast Delegation無非就是一個智能指針數(shù)祖，是不是還有Any-Cast Delegation呢?我不知道，也許有吧，無非就是智能指針數(shù)祖+隨機數(shù)發(fā)生器。

但是，實際上并不是那么簡單。你可以把我剛才說的函數(shù)指針封裝一下弄一個類封裝起來，不過，這直接導(dǎo)致某個消息的響應(yīng)只能是固定死的函數(shù)指針類型，甚至不能是可愛的Functor或者是某個類的成員函數(shù)。你可能會跟我抬杠說這怎么可能，不是可以用template實現(xiàn)么?我們來看一個例子

假設(shè)某個委托類 Dummy_Delegation 擁有一個成員函數(shù)用來連接處理函數(shù) template ＜class T＞ void Dummy_Delegation::Connect(T _F); 沒錯，_F可以不一定函數(shù)指針，也可以是Functor，我們利用_F()來呼叫響應(yīng)函數(shù)，一切看起來是多么美好——但是，很不幸，這個_F無法保存下來供消息產(chǎn)生的時候呼叫。

一切都因為這個該死的template＜class T＞ ，你無法在Dummy_Delegation內(nèi)定義一個T類型的變量或者指針來保存_F。退一萬步說，你把T作為整個Dummy的模版，還是避免不了在模版實例化的時候定死類型。于是，整個Delegation的通用性大打折扣。

實際上，我們希望有這么一種Delegation，他可以把消息響應(yīng)動態(tài)綁定到任何一個類的成員函數(shù)上只要函數(shù)類型一致。注意，這里說的是任何一個類。這就要求我們屏蔽信號發(fā)生器和響應(yīng)類之間的耦合關(guān)系，即，讓他們相互都不知道對方是誰甚至不知道對方的類型信息。

這個方法可行么?Yes!

橋式委托(Bridge Delegation) ---- 利用泛型+多態(tài)來實現(xiàn)

請允許我杜撰一個名詞：橋式委托(Bridge Delegation)

實現(xiàn)這么一個東西真的很有意思，其實，像gtk+/qt很多需要"信號/反饋"(signal/slot)的系統(tǒng)都是這么實現(xiàn)的。

說到GP和Template，那真的可以算是百家爭鳴了，就像boost和loki還在爭奪新的C++標(biāo)準(zhǔn)智能指針的地位打得不可開交。而Functor這個東西有是很多GP algo的基礎(chǔ)，比如sort/for_each等等。

整個橋式委托的結(jié)構(gòu)如下圖：

Signal ＜＞--------＞* Interface  ^  |  Implementation＜Receiver＞ -------------＞ Receiver

我們搭建了一個Interface/Implementation的橋用來連接Singal和Receiver，這樣就可以有效隔開雙方的直接耦合。用之前我們的Socket類來演示如下：

struct Socket {  Signal OnRecv;  };

一個Receiver可以是一個function比如 void OnRecv1() 也可以是一個Functor：

struct OnRecv2_t {  void operator() ();  } OnRecv2;

我們可以這樣使用這個橋式委托

Socket x;  x.OnRecv.ConnectSlot(OnRecv1); //或者 x.OnRecv.ConnectSlot(OnRecv2());

當(dāng)消息產(chǎn)生調(diào)用 x.OnRecv()的時候，用戶指定的OnRecv1或者OnRecv2就會響應(yīng)。

我們來看看如何實現(xiàn)這個橋：首先是一個抽象類

struct DelegationInterface {  virtual ~DelegationInterface() {};  virtual void Action() = 0;  };

然后才是模版類Impl：

template＜class T＞  struct DelegationImpl : public DelegationInterface {  T _FO;  DelegationImpl(T _S) :_FO(_S) { }  virtual void Action() { _FO(); }  };

注意我們上面的圖示，這個DelegationImpl類是跟Receiver相關(guān)聯(lián)的，也就是說這個Impl類知道所有的Receiver細(xì)節(jié)，于是他可以從容地調(diào)用Receiver()。再次留意這個繼承關(guān)系，對了，一個virutal的Action函數(shù)!利用多態(tài)性質(zhì)，我們可以根據(jù)Receiver來實例化DelegationImpl類，卻可以利用提供一致的訪問Action的Interface，這就是整座橋的秘密所在——利用多態(tài)下層隔離細(xì)節(jié)!

再看看我們的Signal類：

struct Signal {  DelegationInterface* _PI;   Signal() :_PI(NULL) {}  ~Signal() { delete _PI; }   void operator()() { if(_PI) _PI-＞Action(); }  template＜class T＞ void ConnectSlot(T Slot) {  delete _PI; _PI = new DelegationImpl＜T＞(Slot);  }  };

顯然，Signal類利用了 DelegationInterface* 指針_PI來呼叫響應(yīng)函數(shù)。而完成這一切連接操作的正是這個奇妙的ConnectSlot的函數(shù)。對了!上次討論模版函數(shù)的時候就說了這個T類型無法保存，但是這里用橋避開了這個問題。利用模版函數(shù)的T做為DelegationImpl的實例化參數(shù)，一切就這么簡單地解決了。

你也許可能會抗議，認(rèn)為我繞了一大圈又繞回了一開始我煩惱的繼承/多態(tài)上面來了。其實，你有沒有發(fā)現(xiàn)，我們這個Singal/Bridge Delegation/Receive的體系是固定的一套東西，你在實際使用中并不需要自己去繼承去處理重載，你只需要好好地Connect到正確的Slot就可以了。這也可以算是一種局部隱含的繼承吧。

接下來我們要討論一下這個橋式委托的性能消耗以及擴展和局限性問題

橋式委托的進一步研究

看過上面的橋式委托之后，可能會有點懷疑他的性能，需要一個interface指針一個functor類/函數(shù)指針，調(diào)用的時候需要一次查vtable，然后再一次做operator()調(diào)用。其實，這些消耗都不算很大的，整個橋式委托的類結(jié)構(gòu)是簡單的，相對于前面說的繼承整個類之類的做法開銷還是比較小的，而且又比函數(shù)指針通用而且類型安全。最重要的是，剛才的Signal可以方便地改寫為Multi-Cast Delegation即一個信號引發(fā)多個響應(yīng)——把Singal內(nèi)部的DelegationInterface*指針改為一個指針隊列就可以了。

不過，我們剛才實現(xiàn)的橋式委托只能接收函數(shù)指針和functor，不能接收另外一個類的成員函數(shù)，有時候這是非常有用的動作。比如設(shè)置一個按鈕Button的OnClick事件的響應(yīng)為一個MsgBox的Show方法。當(dāng)然，MsgBox還有其他非常多的方法，這樣就可以不用局限于把MsgBox當(dāng)成一個functor了。

我們要改寫剛才的整個橋來實現(xiàn)這個功能，在這里需要你對指向成員函數(shù)得指針有所了解。

// 新版的橋式委托，可以接收類的成員函數(shù)作為響應(yīng)  struct DelegationInterface {   virtual ~DelegationInterface() {};  virtual void Run() = 0;  };   template＜class T＞  struct DelegationImpl : public DelegationInterface {  typedef void (T::* _pF_t)(); // 指向類T成員函數(shù)的指針類型   DelegationImpl(T* _PP, _pF_t pF) :_P(_PP), _PF(pF) {}  virtual void Run() {  if(_P) { (_P-＞*_PF)(); } // 成員函數(shù)調(diào)用，很別扭的寫法(_P-＞*_PF)();  }   T* _P; // Receiver類  _pF_t _PF; // 指向Receiver類的某個成員函數(shù)  };  struct Signal  {  DelegationInterface* _PI;  Signal() :_PI(NULL) {}  void operator() () { if(_PI) _PI-＞Run(); }   // 新的ConnectSlot需要指定一個類以及這個類的某個成員函數(shù)  template＜class T＞  void ConnectSlot(T& recv, void (T::* pF)()) { // pF這個參數(shù)真夠別扭的  _PI = new DelegationImpl＜T＞(&recv, pF);  }  };

注意：ConnectSlot方法的pF參數(shù)類型非常復(fù)雜，也可以簡化如下，即把這個類型檢測推到DelegationImpl類去完成，而不在Connect這里進行么?編譯器可以正確識別。對于模板來說，很多復(fù)雜的參數(shù)類型都可以用一個簡單的類型代替，不用關(guān)心細(xì)節(jié)，就象上面用一個F代替void (T::*)()。有時候能改善可讀性，有時候象反。

template＜class T, class F＞  void ConnectSlot( T& recv, F pF ) {  PI_ = new DelegationImpl＜T＞(&recv,pF);  }

這個新版怎么用呢，很簡單的。比如你的MsgBox類有一個成員函數(shù)Show，你可以把這個作為響應(yīng)函數(shù)：

MsgBox box;  Socket x; // Socket還跟舊的版本一樣  x.OnRecv.ConnectSlot(box, &MsgBox::Show);

注意上面這里引用成員函數(shù)指針的寫法，一定不能寫成box.Show，呵呵，希望你還記得成員函數(shù)是屬于類公共的東西，不是某個實例的私有產(chǎn)品。大家不妨進一步動一下腦筋，把新版的Signal和舊版的Signal結(jié)合一下，你就可以獲得一個功能超強的Delegation系統(tǒng)了。

點評：用signal的辦法確實可以方便地動態(tài)替換處理函數(shù)，不過這是以每個可能被處理的消息都要在每個對象中占用一個 signal 的空間為代價的。而且，需要動態(tài)改變處理函數(shù)的應(yīng)用我已經(jīng)不記得什么時候見過了。即使有，也可以通過在override的virtual函數(shù)里自己處理實現(xiàn)，雖說麻煩，但也是可能的。此外，以上代碼并不夠規(guī)范，下劃線加大寫字母開頭的標(biāo)識符是保留給語言的實現(xiàn)用的。

“C++委托和消息反饋模板怎么實現(xiàn)”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！