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