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自行析构就行了。

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

图四

<shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 204.75pt; HEIGHT: 233.25pt" type="#_x0000_t75"><imagedata o:title="boost" src="file:///C:%5CDOCUME~1%5Cpongba%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.gif"></imagedata></shape>

现在的问题是，每当该函数对象连接到一个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*不就够了么？”

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

struct S1:boost::signals::trackable

{//该对象是可跟踪的！但并非一个函数对象

void test(){cout<<"test\n";}

};

...

boost::signal<void()> sig;

{ //一个局部作用域

S1 s1;

sig.connect(boost::bind(&S1::test,boost::ref(s1)));

sig(); //输出 “test”

} //结束该作用域,s1在此析构，断开连接

sig(); //无输出

boost::bind()将&S1::test[4]的“this”参数绑定为s1，从而生成一个“void()”型的仿函数，每次调用该仿函数就相当于调用s1.test()，然而，这个仿函数本身并非可跟踪的，不过，很显然，这里的s1对象一旦析构，则该仿函数就失去了意义，从而应该让连接断开。所以，我们应该使S1类成为可跟踪的（见struct S1的代码）。

然而，这又能说明什么呢？仍然只有一个trackable子对象！但是，答案已经很明显了：既然boost::bind可以绑定一个参数，难道不能绑定两个参数？对于一个延迟调用的函数对象[5]，一旦其某个按引用语义传递的参数析构了，该函数对象也就相应失效了。所以，对于这种函数对象，其按引用传递的参数都应该是可跟踪的。在上例中，s1就是一个按引用传递的参数[6]，所以是可跟踪的。所以，如果有多个这种参数绑定到一个仿函数，就会有多个trackable对象，其中任意一个对象的析构都会导致仿函数失效以及连接的断开。

例如，假设C1,C2类都是trackable的。并且函数test的类型为void(C1,C2)。那么boost::bind(&test,boost::ref(c1),boost::ref(c2))就会返回一个void()型的函数对象，其中c1,c2作为test的参数绑定到了该函数对象。这时候，如果c1或c2析构，这个函数对象也就失效了。如果先前该函数对象曾连接到某个signal<void()>型的signal，则连接应该断开。

问题在于，如何获得绑定到某个函数对象的所有trackale子对象呢？

关键在于visit_each函数——我们回到slot的构造函数（见上文列出的源代码），其第二行代码调用了visit_each函数，该函数负责访问f中的各个trackable子对象，并将它们的地址保存在bound_objects这个vector中。

至于visit_each是如何访问f中的各个trackable子对象的，这并非本文的重点，我建议你自行参考源代码。

slot类的构造函数最后调用了create_connection函数，这个函数创建一个连接对象，表示函数对象和该slot的连接。“咦？为什么和slot连接，函数对象不是和signal连接的吗？”没错。但这个看似蛇足的举动其实是为了实现“delayed connect”，例如：

void delayed_connect(Functor* f)

{

//构造一个slot，但暂时不连接

slot_type slot(*f);

//使用f做一些事情，在这个过程中f可能会被析构掉

...

//如果f已经被析构了，则slot变为inactive态，则下面的连接什么事也不做

sig.connect(slot);

}

...

Functor* pf=new Functor();

delayed_connect(pf);

...

这里，如果在slot连接到sig之前，f“不幸”析构了，则连接不会生效，只是返回一个空连接。

为了达到这个目的，slot类的构造函数使用create_connection构造一个连接，这个连接其实没有实际意义，只是用于“监视”函数对象是否析构。如果函数对象析构了，则该连接会变为“断开”态。下面是create_connection的源代码：

摘自libs/signals/src/slot.cpp

void slot_base::create_connection()

{

basic_connection* con = new basic_connection();

font-size: 12p

分享到：

《boost源码剖析》系列 | boost源码剖析之：多重回调机制signal(上 ...

• 2007-04-11 18:37
• 浏览 347
• 评论(0)
• 查看更多