boost源码剖析之：多重回调机制signal(上)
boost源碼剖析之：多重回調機制signal(上)
?
劉未鵬
C++的羅浮宮(http://blog.csdn.net/pongba)
?
boost庫固然是技術的寶庫，卻更是思想的寶庫。大多數程序員都知道如何應用command，observer等模式，卻不知該如何寫一個支持該模式的類。正如隔靴搔癢，無法深入。DDJ上曾有一篇文章用C++實現類似C#的event機制，不過是個雛形，比之boost.Signal卻又差之甚遠矣。
?
上篇：架構篇
引入
所謂“事件”機制，簡而言之，就是用戶將自己的一個或多個回調函數掛鉤到某個“事件”上，一旦“事件”被觸發，所有掛鉤的函數都被調用。
?
毫無疑問，事件機制是個十分有用且常用的機制，不然C#也不會將它在語言層面實現了。
?
但是C++語言并無此種機制。
?
幸運的是boost庫的開發者們替我們做好了這件事(事實上，他們做的還要更多些)。他們的類稱作signal，即“信號”的意思，當“信號”發出的時候，所有注冊過的函數都將受到調用。這與“事件”本質上完全一樣。
?
簡單情況下，你只需要這樣寫：
?
double?square(double?d){return?pi*r*r;}?//面積
double?circle(double?d){return?2*pi*r;}?//周長
//double(double)是一個函數類型，意即：接受一個double型參數，返回double。
signal<double(double)[1]> sig;
sig.connect(&square);?//向sig注冊square
sig.connect(&circle);//注冊circle
//觸發該信號，sig會自動調用square(3.14)，circle(3.14)，并返回最后一個函數，circle()的返回值
double?c=sig(3.14);??//assert(c==circle(3.14))
?
signal能夠維護一系列的回調函數，并且，signal還允許用戶指定函數的調用順序，signal還允許用戶定制其返回策略，默認情況下返回(與它掛鉤的)最后一個函數的返回值，當然你可以指定你自己的“返回策略”(比如：返回其中的最大值)，其中手法，甚為精巧。另外，如果注冊的是函數對象（仿函數）而非普通函數，則signal還提供了跟蹤能力，即該函數對象一旦析構，則連接自動斷開，其實現更是精妙無比。
?
俗語云：“熟讀唐詩三百首，不會吟詩也會吟”。寫程序更是如此。如果仔細體會，會發現signal的實現里面隱藏了許許多多有價值的思想和模式。何況boost庫是個集泛型技術之大成的庫，其源代碼本身就是一筆財富，對于深入學習C++泛型技術是極好的教材。所以本文不講應用，只講實現，你可以邊讀邊參照boost庫的源代碼[2]。另外，本文盡量少羅列代碼，多分析架構和思想，并且列出的代碼為了簡潔起見，往往稍作簡化[3]，略去了一些細節，但是都注明其源文件，自行參照。
?
在繼續往下讀之前，建議大家先看看boost庫的官方文檔，了解signal的各種使用情況，這樣，在經歷下面繁復的分析過程時心中才會始終有一個清晰的脈絡。事實上，我在閱讀代碼之前也是從各種例子入手的。
?
架構
Signal的內部架構，如果給出它的總體輪廓，非常清晰明了。見下圖：
?
圖一
???????????????
?
顯然，signal在內部需要一個管理設施來管理用戶所注冊的函數（這就是圖中的slot manager），從根本上來說，boost::signal中的這個slot“管理器”就是multimap（如果你不熟悉multimap，可以參考一些STL方面的書籍（如《C++ STL》《泛型編程與STL》）或干脆查詢MSDN。這里我只簡單的說一下——multimap將鍵（key）映射(map)到鍵值（鍵和鍵值的類型可以是任意），就像字典將字母映射到頁碼一樣。）它負責保存所謂的slot，每一個slot其實本質上是一個boost::function[4]函數對象，該函數對象封裝了用戶注冊給signal回調的函數（或仿函數）。當然，slot是經過某種規則排序的。這正是signal能夠控制函數調用順序的原因。
?
當你觸發signal時，其內部迭代遍歷“管理器”——multimap，找出其中保存的所有函數或函數對象并逐一調用它們。
?
聽起來很簡單，是不是？但是我其實略去了若干細節，譬如，如何讓用戶控制某個特定的連接？如何控制函數的調用順序？如何實現可定制的返回策略？等等。
?
看來設計一個“industry-strength”的signal并非一件易事。事實上，非常不易。然而，雖然我們做不到，卻可以看看大師們的手筆。
?
我們從signal的最底層布局開始，signal的底層布局十分簡單，由一個基類signal_base_impl來實現。下面就是該基類的代碼：
?
摘自boost/signals/detail/signal_base.hpp
class?signal_base_impl {
public:
typedef?function2<bool, any, any> compare_type;
private:
typedef?std::multimap<any,?connection_slot_pair, compare_type>slot_container_type;?//以multimap作為slot管理器的類型
?
????//遍歷slot容器的迭代器類型
typedef?slot_container_type::iterator slot_iterator;
?????//slot容器內部元素的類型，事實上，那其實就是std::pair<any,connection_slot_pair>。
????typedef?slot_container_type::value_type stored_slot_type;
?
?????//這就是slot管理器，唯一的數據成員——一個multimap，負責保存所有的slot。
????mutable?slot_container_type?slots_;
...
};
?
可以看出slot管理器的類型是個multimap，其鍵（key）類型卻是any[5]，這是個泛型的指針，可以指向任何對象，為什么不是整型或其它類型，后面會為你解釋。
以上是主要部分，你可能會覺得奇怪，為什么保存在slot管理器內部的元素類型是個怪異的connection_slot_pair而不是boost::function，前面不是說過，slot本質上就是boost::function對象么？要尋求答案，最好的辦法就是看看這個類型定義的代碼，源代碼會交代一切。下面就是connection_slot_pair的定義：
?
摘自boost/signals/connection.hpp
struct?connection_slot_pair {
//connection類用來表現“連接”這個概念，用戶通過connection對象來控制相應的連接，例如，調用成員函數disconnect()則斷開該連接
connection?first;
//any是個泛型指針類，可以指向任何類型的對象
????any?second;
//封裝用戶注冊的函數的boost::function對象實際上就由這個泛型指針來持有
...
};
?
原來，slot管理器內部的確保存著boost::function對象，只不過由connection_slot_pair里的second成員——一個泛型指針any——來持有。并且，還多出了一個額外的connection對象——很顯然，它們是有關聯的——connection成員表現的正是該function與signal的連接。為什么要多出這么一個成員呢?原因是這樣的：connection一般掌握在用戶手中，代碼象這樣：
?
connection con=sig.connect(&f); //?通過con來控制這個連接
?
而signal如果在該連接還沒有被用戶斷開（即用戶還沒有調用con.disconnect()）前就析構了，自然要將其中保存的所有slot一一摧毀，這時候，如果slot管理器內部沒有保存connection的副本，則slot管理器就無法對每個slot一一斷開其相應的連接，從而控制在用戶手中的connection對象就仿佛一個成了一個野指針，這是件很危險的事情。從另一個方面說，既然slot管理器內部保存了connection的副本，則只要讓這些connection對象析構的時候能自動斷開連接就行了，這樣，即使用戶后來還試圖斷開手里的con連接，也能夠得知該連接已經斷開了，不會出現危險。有關connection的詳細分析見下文。
?
根據目前的分析，signal的架構可以這樣表示：
?
圖二
????
?
boost::signals::connection類
connection類是為了表現signal與具體的slot之間的“連接”這種概念。signal將slot安插妥當后會返回一個connection對象，用戶可以持有這個對象并以此操縱與它對應的“連接”。而每個slot自己也和與它對應的connection呆在一起(見上圖)，這樣slot管理器就能夠經由connection_slot_pair中的first元素來管理“連接”，也就是說，當signal析構時，需要斷開與它連接的所有slot，這時就利用connection_slot_pair中的first成員來斷開連接。而從實際上來說，slot管理器在析構時卻又不用作任何額外的工作，只需按部就班的析構它的所有成員(slot)就行了，因為connection對象在析構時會考慮自動斷開連接（當其內部的is_controlling標志為true時）。
?
要注意的是，對于同一個連接可能同時存在多個connection對象來表現（和控制）它，但始終有一個connection對象是和slot呆在一起的，以保證在signal析構時能夠斷開相應的連接，其它連接則掌握在用戶手中，并且允許拷貝。很顯然，一旦實際的連接被某個connection斷開，則對應于該連接的其它connection對象應該全部失效，但是庫的設計者并不知道用戶什么時候會拷貝connection對象和持有多少個connection對象，那么用戶經過其中一個connection對象斷開連接時，其它connection對象又是如何知道它們對應的連接是否已經斷開呢？原因是這樣的：對于某個特定連接，真正表現該連接的只有唯一的一個basic_connection對象。而connection對象其實只是個外包類，其中有一個成員是個shared_ptr[6]類型的智能指針，從而對應于同一個連接的所有connection對象其實都通過這個智能指針指向同一個basic_connection對象，后者唯一表現了這個連接。經過再次精化后的架構圖如下：
?
圖三
?
這樣，當用戶通過其中任意一個connection對象斷開連接（或signal通過與slot保存在一塊的connection對象斷開連接）時，connection對象只需轉交具體表現該連接的唯一的basic_connection對象，由它來真正斷開連接即可。這里，需要注意的是，斷開連接并非意味著唯一表示該連接的basic_connection對象的析構。前面已經講過，connection類里有一個shared_ptr智能指針指向basic_connection對象，所以，當指向basic_connection的所有connection都析構掉后，智能指針自然會將basic_connection析構。其實更重要的原因是，從邏輯上，basic_connection還充當了信息中介——由于控制同一連接的所有connection對象都共享它，從而都可以查看它的狀態來得知連接是否已經斷開，如果將它delete掉了，則其它connection就無從得知連接的狀態了。所以這種設計是有良苦用心的。正因此，一旦某個連接被斷開，則對應于它的所有connection對象都可得知該連接已經斷開了。
?
對于connection，還有一個特別的規則：connection對象分為兩種，一種是“控制性”的，另一種是“非控制性”的。掌握在用戶手中的connection對象為“非控制性”的，也就是說析構時不會導致連接的斷開——這符合邏輯，因為用戶手中的connection對象通常只是暫時的復制品，很快就會因為結束生命期而被析構掉，況且，signal::connect()返回的connection對象也是臨時對象，用戶可以選擇丟棄該返回值（即不用手動管理該連接），此時該返回值會立即析構，這當然不應該導致連接的斷開，所以這種connection對象是“非控制性”的。而保存在slot管理器內部，與相應的slot呆在一起的connection對象則是“控制性”的，一旦析構，則會斷開連接——這是因為它的析構通常是由signal對象的析構導致的，所謂“樹倒猢猻散”，signal都不存在了，當然要斷開所有與它相關的連接了。
?
了解了這種架構，我們再來跟蹤一下具體的連接過程。
?
連接
向signal注冊一個函數（或仿函數）甚為簡單，只需調用signal::connect()并將該函數（或仿函數）作為參數傳遞即可。不過，要注意的是，注冊普通函數時需提供函數的地址才行（即“&f”），而注冊函數對象時只需將對象本身作為參數。下面，我們從signal::connect()開始來跟蹤signal的連接過程。
?
前提:下面跟蹤的全過程都假設用戶注冊的是普通函數，這樣有助于先理清脈絡，至于注冊仿函數（即函數對象）時情況如何，將在高級篇中分析。
?
源代碼能夠說明一切，下面就是signal::connect()的代碼：
?
?????template<...>
?????connection signal<...>::connect(const?slot_type& in_slot)
?????{...}
?
這里，我們先不管connect()函數內部是如何運作的，而是集中于它的唯一一個參數，其類型卻是const slot_type&，這個類型其實對用戶提供的函數（或仿函數）進行一重封裝——封裝為一個“slot”。至于為什么要多出這么一個中間層，原因只是想提供給用戶一個額外的自由度，具體細節容后再述。
?
slot_type其實只是一個位于signal類內部的typedef，其真實類型為slot類。
?
很顯然，這里，slot_type的構造函數將被調用（參數是用戶提供的函數或仿函數）以創建一個臨時對象，并將它綁定到這個const引用。下面就是它的構造函數：
?
?????template<typename?F>
????slot(const?F& f) : slot_function(f)
????{
??????...?//這里，我們先略過該構造函數里面的代碼（后面再回顧）
}
?
可以看出，用戶給出的函數（或仿函數）被封裝在slot_function成員中，slot_function的類型其實是boost::function<...>，這是個泛型的函數指針，封裝任何簽名兼容的函數及仿函數。將來保存在slot管理器內部的就是它。
?
下面，slot臨時對象構造完畢，仍然回到signal::connect()來：
?
摘自boost/signals/signal_template.hpp
connection signal<...>::connect(const?slot_type& in_slot)
{
?????...
?????????return?impl->connect_slot(in_slot.get_slot_function(),
??????????????????????????????any(),
??????????????????????????????in_slot.get_bound_objects());
}
?
這里，signal將一切又交托給了其基類的connect_slot()函數，并提供給它三個參數，注意，第一個參數in_slot.get_slot_function()返回的其實正是剛才所說的slot類的成員slot_function，也正是將要保存在slot管理器內部的boost::function對象。而第二個參數表示該用戶注冊函數的優先級，
?
signal::connect()其實有兩個重載版本，第一個只有一個參數，就是用戶提供的函數，第二個卻有兩個參數，其第一個參數為優先級，默認是一個整數。這里，我們考察的是只有一個參數的版本，意味著用戶不關心該函數的優先級，所以默認構造一個空的any()對象（回憶一下，slot管理器的鍵（key）類型為any）。至于第三個參數僅在用戶注冊函數對象時有用，我們暫時略過，在高級篇里再詳細敘述。現在，繼續追蹤至connect_slot()的定義：
?
摘自libs/signals/src/signal_base.cpp
connection
??????signal_base_impl::
????????connect_slot(const?any& slot,
?????????????????????const?any& name,
?????????????????????const?std::vector<const trackable*>& bound_objects)
//最后一個參數當用戶提供仿函數時方才有效，容后再述
{
?????//創建一個basic_connection以表現本連接——注意，一個連接只對應于一個basic_connection對象，但可以有多個connection對象來操縱它。具體原因上文有詳述。
????????basic_connection* con =?new?basic_connection();
????????connection slot_connection;
????????slot_connection.reset(con);
?
????????std::auto_ptr<slot_iterator> saved_iter(new?slot_iterator());
?
?????//用戶注冊的函數在此才算真正在signal內部安家落戶——即將它插入到slot管理器(multimap)中去
????slot_iterator pos =
????????????????slots_.insert(stored_slot_type(name,
connection_slot_pair(slot_connection,slot)
));
//保存在slot管理器內部的connection對象應該設為“控制性”的。具體原因上文有詳述。
????????pos->second.first.set_controlling();
????????*saved_iter = pos;
//下面設置表現本連接的basic_connection對象的各項數據，以便管理該連接。
????????con->signal?=?this;?//指向連接到的signal
????????con->signal_data?= saved_iter.release();//一個iterator，指出回調函數在signal中的slot管理器中的位置
????????con->signal_disconnect?= &signal_base_impl::slot_disconnected;?//如果想斷開連接，則應該調用此函數，并將前面兩項數據作為參數傳遞過去，則回調函數將被從slot管理器中移除。
????????????...
????????return?slot_connection;//返回該連接
}
?
這個函數結束后，連接也就創建完了，看一看最后一行代碼，正是返回該連接。
?
從上面的代碼可以看出，basic_connection對象有三個成員：signal，signal_data，signal_disconnect，這三個成員起到了控制該連接的作用。源代碼上的注釋已經提到，成員signal指向連接到的是哪個signal。而signal_data其實是個iterator，指明了該slot在slot管理器中的位置。最后，成員signal_disconnect則是個void(*)(void*,void*)型的函數指針，指向一個static成員函數——signal_base_impl::slot_disconnected。以basic_connection中的signal和signal_data兩個成員作為參數來調用這個函數就能夠斷開該連接。即：
?
(*signal_disconnect)(local_con->signal, local_con->signal_data);
?
然而，具體如何斷開連接還得看slot_disconnected函數的代碼（注意將它和上面的connect_slot函數的代碼作一個比較，它們是幾乎相反的過程）
?
摘自libs/signals/src/signal_base.cpp
void?signal_base_impl::slot_disconnected(void* obj,?void* data)
{
????signal_base_impl* self =?reinterpret_cast<signal_base_impl*>(obj);//指明連接到的是哪個signal
?
?????//指出slot在slot管理器中的位置
????std::auto_ptr<slot_iterator> slot(
???????????????????????????reinterpret_cast<slot_iterator*>(data));
...?//省略部分代碼。
????self->slots_.erase(*slot);//將相應的slot從slot管理器中移除
}
?
值得注意的是，basic_connection中的兩個成員:signal和signal_data的類型都是void*，具體原因在高級篇里會作解釋。而slot_disconnected函數的代碼不出所料：先將兩個參數的類型轉換為合適的類型，還其本來面目：一個是signal_base_impl*，另一個是指向迭代器的指針：slot_iterator*，然后調用slots_[7]上的erase函數將相應的slot移除，就算完成了這次disconnect。這簡直就是connect_slot()的逆過程。
?
這里，你可能會有疑問：這樣就算斷開了連接？那么用戶如果不慎通過某個指向該basic_connection的connection再次試圖斷開連接又當如何呢？更可能的情況是，用戶想要再次查詢該連接是否斷開。如此說來，basic_connection中是否應該有一個標志，表示該連接是否已斷開？完全不必，其第三個成員signal_disconnect是個函數指針，當斷開連接后，將它置為0，不就是個天然的標志么？事實上，connection類的成員函數connected()就是這樣查詢連接狀態的：
?
摘自boost/signals/connection.hpp
bool?connected()?const
{
return?con.get() && con->signal_disconnect;
}
?
再次提醒一下，con是個shared_ptr，指向basic_connection對象。并且，尤其要注意的是，連接斷開后，表示該連接的basic_connection對象并不析構，也不能析構，因為它還要充當連接狀態的標志，以供仍可能在用戶手中的connection對象來查詢。當指向它的所有connection對象都析構時，根據shared_ptr的規則，它自然會析構掉。
?
好了，回到主線，連接和斷開連接的大致過程都已經分析完了。其中我略去了很多技術細節，盡量使過程簡潔，這些技術細節大多與仿函數有關——假若用戶注冊的是個仿函數，就有得折騰了，其中曲折甚多，我會在高級篇里詳細分析。
?
排序
跟蹤完了連接過程，下面是真正的調用過程，即觸發了signal，各個注冊的函數均獲得一次調用，這個過程邏輯上頗為簡單：從slot管理器中將它們一一取出并調用一次不就得了？但是，正如前面所說的，調用可是要考慮順序的，各個函數可能有著不同的優先級，這又該如何管理呢？問題的關鍵就在于multimap的排序，一旦將函數按照用戶提供的優先級排序了，則調用時只需依次取出調用就行了。那么，排序準則是什么呢？如你所知，一個signal對象sig允許注冊這樣一些函數：
?
sig.connect(&f0);?//f0沒有優先級
sig.connect(1,&f1);//f1的優先級為1
sig.connect(2,&f2);?//f2的優先級為2
sig.connect(&f3);?//f3沒有優先級
?
這時候，這四個函數的順序是f1,f2,f0,f3。準則這樣的，如果用戶為某個函數提供了一個優先級，如1，2等，則按優先級排序，如果沒有提供，則相應函數追加在當前函數隊列的尾部。這樣的排序準則如何實現呢，很簡單，只需要將一個仿函數提供給multimap來比較它的鍵，multimap自己會排序妥當，這個仿函數如下：
?
摘自boost/signals/detail/signal_base.hpp
template<typename?Compare,?typename?Key>
????class?any_bridge_compare {
?????????????...
?????????//slot管理器的鍵類型為any，所以該仿函數的兩個參數類型都是any
????????bool?operator()(const?any& k1,?const?any& k2)?const
????????{
??????????//如果k1沒有提供鍵（如f0，它的鍵any是空的）則它處于任何鍵之后
??????????if?(k1.empty())
????????????return?false;
??????????//如果k2沒有提供鍵，則任何鍵都排在它之前
??????????if?(k2.empty())
????????????return?true;
??????????//如果兩個鍵都存在，則將鍵類型轉換為合適的類型再作比較
??????????return?comp(*any_cast<Key>(&k1), *any_cast<Key>(&k2));
????????}
??????private:
????????Compare comp;
};
?
這個仿函數就是提供給slot管理器來將回調函數排序的仿函數。它的比較準則為：首先看k1是否為空，如果是，則在任何鍵之后。再看k2是否為空，如果是，則任何鍵都在它之前。否則，如果兩者都非空，則再另作比較。并且，從代碼中看出，這最后一次比較又轉交給了Compare這個仿函數，并事先將鍵轉型為Key類型（既然非空，就可以轉型了）。Key和Compare這兩個模板參數都可由用戶定制，如果用戶不提供，則為默認值：Key=int,Compare=std::less<int>。
?
現在你大概已經明白為什么slot管理器要以any作為其鍵(key)類型了，正是為了實現“如果用戶不指定優先級，則優先級最低”的語義。試想，如果用戶指定什么類型，slot管理器的鍵就是什么類型——如int，那么哪個值才能表示“最低優先級”這個概念呢？正如int里面沒有值可以表現“負無窮大”的概念一樣，這是不可能的。但是，如果用一個指針來指向這個值，那么當指針空著的時候，我們就可以說“這是個特殊的值”，本例中，這個特殊值就代表“優先級最低”，而當指針非空時，我們再來作真正的比較。況且，any是個特殊的指針，你可以以類型安全的方式(通過一個any_cast<>)從中取出你先前保存的任何值（如果類型不符，則會拋出異常）。
?
回顧上面的例子，對于f0,f3沒有提供相應的鍵，從而構造了一個空的any()對象，根據前面所講的比較準則，其“優先級最低”，并且，由于f3較晚注冊，所以在最末端（想想前面描述的比較準則）。
?
當然，用戶也可以定制
Key=std::string，
Compare=std::greater<std::string>。
總之一切按你的需求。
?
回調
下面要分析的就是回調了。回調函數已經連接到signal，而觸發signal的方式很簡單，由于signal本身就是一個函數對象，所以可以這樣：
?
?????signal<int(int,double)> sig;
?????sig.connect(&f1);
?????sig.connect(&f2);
?????int ret=sig(0,3.14);?//正如調用普通函數一樣
?
前面提到過，signal允許用戶定制其返回策略（即，返回最大值，或最小值等），默認情況下，signal返回所有回調函數的返回值中的最后一個值，這通過一個模板參數來實現，在signal的模板參數中有一個名為Combiner，是一個仿函數，默認為：
?
typename Combiner = last_value<R>
?
last_value是個仿函數，它有兩個參數，均為迭代器，它從頭至尾遍歷這兩個迭代器所表示的區間，并返回最后一個值，算法定義如下：
?
?????摘自boost/last_value.hpp
????T?operator()(InputIterator first, InputIterator last)?const
????{
??????T value = *first++;
??????while?(first != last)
????????value = *first++;
??????return?value;
}
?
我本以為signal會以一個簡潔的for_each遍歷slot管理器，輔以一個仿函數來調用各個回調函數，并將它們的返回值緩存為一個序列，而first和last正指向該序列的頭尾。然后在該序列上應用該last_value算法（返回策略），從而返回恰當的值。這豈非很自然？
?
但是很明顯，將各個回調函數的返回值緩存為一個序列需要消耗額外的空間和時間，況且我在signal的operator()操作符的源代碼里只發現一行！就是將last_value應用于一個區間。在此之前找不到任何代碼是遍歷slot管理器并一一調用回調函數的。但回調函數的確被一一調用了，只不過方式很巧妙，也很隱藏，并且更簡潔。繼續往下看。
?
從某種程度上說，參數first指向slot管理器(multimap)的區間頭，而last指向其尾部。但是，既然該仿函數名為last_value，那么直接返回*(--last)豈不更省事？為何非要在區間上每前進一步都要對迭代器解引用呢（這很關鍵，后面會解釋）？況且，函數調用又在何處呢？slot管理器內保存的只不過是一個個函數，遍歷它，取出函數又有何用？問題的關鍵在于，first并非單純的只是slot管理器的迭代器，而是一個iterator_adapter，也就是說，它將slot管理器(multimap)的迭代器封裝了一下，從而對它解引用的背后其實調用了函數。有點迷惑？接著往下看：
?
iterator_facade(iterator_adapter)
iterator_facade(iterator_adapter)在boost庫里面是一個獨立的組件，其功能是創建一個具有iterator外觀（語義）的類型，而該iterator的具體行為卻又完全可以由用戶自己定制。具體用法請參考boost庫的官方文檔。這里我們只簡單描述其用途。
?
上面提到，傳遞給last_value<>仿函數的兩個迭代器是經過封裝的，如何封裝呢？這兩個迭代器的類型為slot_call_iterator，這正是個iterator_adapter，其代碼如下：
?
摘自boost/signals/detail/slot_call_iterator.hpp
?????template<typename?Function,?typename?Iterator>
class?slot_call_iterator?//參數first的類型其實是這個
?????????:public?iterator_facade<...>
{
?????...
?????????dereference()?const
????????{
??????????????return?f(*iter);?//調用iter所指向的函數
????}
};
?
iterator_facade是個模板類，其中定義了迭代器該有的一切行為如：operator ++,operator --,operator *等，但是具體實施該行為的卻是其派生類(這里為slot_call_iterator)，因為iterator_facade會將具體動作轉交給其派生類來執行，比如，operator*()在iterator_facade中就是這樣定義的：
?
reference?operator*()?const
????{
?????????//轉而調用派生類的dereference()函數
?????????return?this->derived().dereference();
}
?
而派生類的dereference()函數在前面已經列出了，其中只有一行代碼：return f(*iter)，iter自然是指向slot管理器內部的迭代器了，*iter返回的值當然是connection_slot_pair[8]，下面只需要取出這個pair中的second成員[9]，然后再調用一下就行了。但是為什么這里的代碼卻是f(*iter)，f是個什么東東？在往下跟蹤會發現，事實上，f保存了觸發signal時提供的各個參數（在上面的例子中，是0和3.14）而f其實是個仿函數，f(*iter)其實調用了它重載的operator()，后者才算完成了對slot的真正調用，代碼如下：
?
?????摘自boost/signals/signal_template.hpp：
????R?operator()(const?Pair& slot)?const
????{
????????F* target =?const_cast<F*>(any_cast<F>(&slot.second.second[10]));
????????return?(*target)(args->a1,args->a2);//真正的調用在這里！！！
}
?
這兩行代碼應該很好理解：首先取出保存在slot管理器(multimap)中的function（通過一個any_cast<>），然后調用它，并將返回值返回。
?
值得說明的是，args是f的成員，它是個結構體，封裝了調用參數，對于本例，它有兩個成員a1,a2，分別保存的是signal的兩個參數（0和3.14）。而類型F對于本例則為boost::function<int(int,double)>[11]，這正是slot管理器內所保存的slot類型，前面已經提到，這個slot由connection_pair里面的second(一個any類型的泛型指針)來持有，所以這里出現了any_cast<>，以還其本來面目。
?
所以說，slot_call_iterator這個迭代器的確是在遍歷slot管理器，但是對它解引用其實就是在調用當前指向的函數，并返回其返回值。了解到這一點，再回顧一下last_value的代碼，就不難理解為什么其算法代碼中要步步解引用了——原來是在調用函數！
?
簡而言之，signal的這種調用方式是“一邊迭代一邊調用一邊應用返回策略”，三管齊下。
?
“這太復雜了”你抱怨說：“能不能先遍歷slot管理器，依次調用其內部的回調函數，然后再應用返回策略呢？”。答案是當然能，只不過如果那樣，就必須先將回調函數的返回值緩存為一個序列，這樣才能在其上應用返回策略。哪有三管齊下來得精妙？
?
現在，你可以為signal定制返回策略了，具體的例子參考libs/signals/test/signal_test.cpp。
?
后記
本文我們只分析了signal的大致架構。雖然內容甚多，但其實只描述了signal的小部分。其中略去了很多技術性的細節，例如slot管理器內保存的函數對象為什么要用any來持有。而不直接為function<...>，還有slot管理器里的調用深度管理——即如果某個回調函數要斷開自身與signal的連接該如何處理。還有，對slot_call_iterator解引用時其實將函數調用的返回值緩存了起來（文中列出的代碼為簡單起見，直接返回了該返回值），如何緩存，為什么要緩存？還有，為什么basic_connection中的signal和signal_data成員的類型都是void*？還有signal中所用到的種種泛型技術等等。
?
當然，細節并非僅僅是細節，很多精妙的東西就隱藏在細節中。另外，我們沒有分析slot類的用處——不僅僅作為中間層。最后，一個最大的遺留問題是：如果注冊的是函數對象，如何跟蹤其析構，這是個繁雜而精妙的過程，需要篇幅甚多。
?
這些都會在下篇——高級篇中一一水落石出。
?
目錄(展開《boost源碼剖析》系列文章)
?
[1]?double(double)是個類型，函數類型。所謂函數類型可以看作將函數指針類型中的’(*)’去掉后得到的類型。事實上，函數類型在面臨拷貝語義的上下文中會退化為函數指針類型。
[2]?boost庫的源代碼可從sf.boost.org網站獲得。目前的版本是1.31.0。
[3]?boost庫的源代碼里面宏和泛型用得極多，的確很難讀懂，所以本文中列出的代碼都是簡單起見，只取出其中最關鍵的部分。所有的宏都已展開，所以，有些代碼與boost庫里的源代碼有些不同。
[4]?boost::function是個泛型的函數指針類，例如boost::function<int(int,double)>可以指向任何類型為int(int,double)的函數或仿函數。
[5]?boost::any也是boost庫的一員。它是個泛型指針，可以指向任意對象，并可以從中以類型安全的方式取出保存的對象。
[6]?顧名思義，即帶有共享計數的指針，boost庫里面有很多種智能指針，此其一
[7]?slots_是signal_base_impl中的唯一的數據成員，也就是slot管理器。請回顧前面的源代碼。
[8]?這里為了簡單起見才這樣講，其實*iter返回的類型是std::pair<any,conection_slot_pair>,any為multimap的鍵(key)類型。
[9]?前面已經提到過，這個second成員是個any類型的泛型指針，指向的其實就是boost::function，后者封裝了用戶注冊的函數或函數對象。
[10]?前面已經提到了，slot管理器內保存的是個connection_slot_pair，其second成員是any，指向boost::function對象，而slot管理器本身是個multimap，所以其中保存的值類型是std::pair<any,conection_slot_pair>，*iter返回的正是這個類型的值，所以這里需要取兩次second成員：slot.second.second。
[11]?再次提醒，boost::function<int(int,double)>可以指向任何類型為int(int,double)的函數或函數對象，本例中，f1,f2,f3,f4函數的類型都是int(int,double)。
總結
以上是生活随笔為你收集整理的boost源码剖析之：多重回调机制signal(上)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： boost源码剖析之：泛型函数指针类bo
- 下一篇： boost源码剖析之：多重回调机制sig