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

boost源码剖析之：多重回调机制signal(下) 刘未鹏 C++的罗浮宫(/pongba) 在本文的上篇中，我们大刀阔斧的剖析了signal的架构。不过还有很多精微之处没有提到，特别是一个遗留问题还没有解决：如果用户注册的是函数对象（仿函数），signal又当如何处理呢？ 下篇：高级篇 概述 在本文的上篇中，我们已经分析了signal的总体架构。至于本篇，我们则主要集中于将函数对象（即仿函数）连接到signal的来龙去脉。signal库的作者在这个方面下了很多功夫，甚至可以说，并不比构建整个signal架构的功夫下得少。 之所以为架构，其中必然隐藏着一些或重要或精妙的思想。 学过STL的人都知道，函数对象 函数对象即重载了operator()操作符的对象，故而可以以与函数调用一致的语法形式来“调用”。又称为functor，中文译为“仿函数”。 (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::listconnection connection_list; typedef connection_list::iterator connection_iterator; mutable connection_list connected_signals; ... } connected_signals是个list，其中保存的是该函数对象所连接到的signals。只不过是以connection的形式来表示的。这些connection都是“控制性” “控制性”是指该connection析构时会顺便将该连接断开。反之则不然。关于“控制性”和“非控制性”的connection的详细讨论见本文的上篇。 的，一旦析构则自动断开连接。所以，trackable析构时根本不需要任何额外的动作，只要让该list自行析构就行了。 了解了这一点，就可以画出可跟踪的函数对象的基本结构，如图四： 图四 现在的问题是，每当该函数对象连接到一个signal，都会将相应connection的一个副本插入到其trackable子对象的connected_signals成员(一个list)中去。然而，这个插入究竟发生在何时何地呢？ 在本文的上篇中曾经分析过连接的过程。对于函数对象，这个过程仍然是一样。不过，当时略过了一些细节，这些细节正是与函数对象相关的。现在一一道来： 如你所知，在将函数(对象)连接到signal时，函数(对象)会先被封装成一个slot对象，slot类的构造函数如下： slot(const F f):slot_function(get_invocable_slot(f