boost源码剖析之：多重回调机制signal(下)

boost源码剖析之：多重回调机制signal(下)

 

刘未鹏

C++的罗浮宫(http://blog.csdn.net/pongba)

 

在本文的上篇中，我们大刀阔斧的剖析了signal的架构。不过还有很多精微之处没有提到，特别是一个遗留问题还没有解决：如果用户注册的是函数对象（仿函数），signal又当如何处理呢？

 

下篇：高级篇

概述

在本文的上篇中，我们已经分析了signal的总体架构。至于本篇，我们则主要集中于将函数对象（即仿函数）连接到signal的来龙去脉。signal库的作者在这个方面下了很多功夫，甚至可以说，并不比构建整个signal架构的功夫下得少。

 

之所以为架构，其中必然隐藏着一些或重要或精妙的思想。

 

学过STL的人都知道，函数对象[1](function object)是STL中的重要概念和基石之一。它使得一个对象可以像函数一样被“调用”，而调用形式又是与函数一致的。这种一致性在泛型编程中乃是非常重要的，它意味着“泛化”，而这正是泛型世界所有一切的基础。而函数对象又由于其携带的信息较之普通函数大为丰富，从而具有更为强大的能力。

 

所以signal简直是“不得不”支持函数对象。然而函数对象又和普通函数不同：函数对象会析构。问题在于：如果某个函数对象连接到signal，那么，该函数对象析构时，连接是否应该断开呢？这个问题，signal的设计者留给用户来选择：如果用户觉得函数对象一旦析构，相应的连接也应该自动断开，则可以将其函数对象派生自boost::signals::trackable类，意即该对象是“可跟踪”的。反之则不用作此派生。这种跟踪对象析构的能力是很有用的，在某些情况下，用户需要这种语义：例如，一个负责数据库访问及更新的函数对象，而该对象的生命期受某个管理器的管理，现在，将它连接到某个代表用户界面变化的signal，那么，当该对象的生命期结束时，对应的连接显然应该断开——因为该对象的析构意味着对应的数据库不再需要更新了。

 

signal库支持跟踪函数对象析构的方式很简单，只要将被跟踪的函数对象派生自boost::signals::trackable类即可，不需要任何额外的步骤。解剖这个trackable类所隐藏的秘密正是本文的重点。

 

架构

很显然，trackable类是整个问题的关键。将函数对象派生自该类，就好比为函数对象安上了一个“跟踪器”。根据C++语言的规则，当某个对象析构时，先析构派生层次最高(most derived)的对象，再逐层往下析构其子对象。这就意味着，函数对象的析构最终将会导致其基类trackable子对象的析构，从而在后者的析构函数中，得到断开连接的机会。那么，哪些连接该断开呢？换句话说，该断开与哪些signal的连接呢？当然是该函数对象连接到的signals。而这些连接则全部保存在一个list里面。下面就是trackable的代码：

 

     class trackable {

         typedef std::list<connection> connection_list;

        typedef connection_list::iterator connection_iterator;

        mutable connection_list connected_signals;

         ...                   

     }

 

connected_signals是个list，其中保存的是该函数对象所连接到的signals。只不过是以connection的形式来表示的。这些connection都是“控制性”[2]的，一旦析构则自动断开连接。所以，trackable析构时根本不需要任何额外的动作，只要让该list自行析构就行了。

 

了解了这一点，就可以画出可跟踪的函数对象的基本结构，如图四：

 

图四

 

现在的问题是，每当该函数对象连接到一个signal，都会将相应connection的一个副本插入到其trackable子对象的connected_signals成员(一个list)中去。然而，这个插入究竟发生在何时何地呢？

 

在本文的上篇中曾经分析过连接的过程。对于函数对象，这个过程仍然是一样。不过，当时略过了一些细节，这些细节正是与函数对象相关的。现在一一道来：

 

如你所知，在将函数(对象)连接到signal时，函数(对象)会先被封装成一个slot对象，slot类的构造函数如下：

 

     slot(const F& f):slot_function(get_invocable_slot(f,tag_type(f)))

     {

       //一个visitor，用于访问f中的每个trackable子对象

       bound_objects_visitor  do_bind(bound_objects);

       //如果f为函数对象，则访问f中的每一个trackable子对象

      visit_each(do_bind,get_inspectable_slot[3](f,tag_type(f)));

       //创建一个connection，表示f与该slot的连接，这是为了实现“delayed-connect”

      create_connection();

}

 

bound_objects是slot类的成员，其类型为vector<const trackable*>。可想而知，经过第二行代码“visit_each(...)”的调用，该vector中保存的将是指向f中的各个trackable子对象的指针。

 

“等等！”你敏锐的发现了一个问题：“前面不是说过，如果用户要让他的函数对象成为可跟踪的，则将该函数对象派生自trackable对象吗？那么，也就是说，如果f是个“可跟踪”的函数对象，那么其中的trackable子对象当然只有一个（基类对象）！但为什么这里bound_objects的类型却是一个vector呢？单单一个trackable*不就够了么？”

 

在分析这个问题之前，我们先来看一段例子代码：