Boost源码剖析：C++泛型函数指针类
2008-03-08 21:26:27 来源：WEB开发网核心提示：前奏 如你所知，Boost库是个特性完备，Boost源码剖析：C++泛型函数指针类，且具备工业强度的库，众多C++权威的参与使其达到了登峰造极的程度，以控制function所能支持的函数参数个数的最大值，其中的function0,function1,function2等名字也由宏扩展出，尤其泛型的强大威力在其中被发挥得
前奏
如你所知，Boost库是个特性完备，且具备工业强度的库，众多C++权威的参与使其达到了登峰造极的程度。尤其泛型的强大威力在其中被发挥得淋漓尽致，令人瞠目结舌。
然而弱水三千，我们只取一瓢饮。下面，我试图从最单纯的世界开始，一步一步带领你进入源码的世界，去探究boost::function(下文简称function)内部的精微结构。
通常 ，在单纯的情况下，对函数的调用简单而且直观，像这样：
int fun(int someVal);
int main(){
fun(10);
}
然而你可能需要在某个时刻将函数指针保存下来，并在以后的另一个时刻调用它，像这样：
int fun(int);
typedef int (*func_handle)(int);
int main(){
func_handle fh=fun;
... //do something
fh(10);
}
但是，假如fun形式为void fun(int)呢？如你所见，fun可能有无数种形式，假如对fun的每一个形式都typedef一个对应的func_handle，则程序员会焦头烂额，不胜其扰，代码也可能变得臃肿和丑陋不堪，甚至假如fun是仿函数呢？
幸运的是C++泛型可以使代码变得优雅精致，面对无数种的可能，泛型是最好的选择。 因此，你只是需要一个能够保存函数指针的泛型模板类(对应于Command模式)，因为泛型编程有一个先天性的优势——可以借助编译器的力量在编译期根据用户提供的型别信息化身千万(具现化)，所以一个泛型的类可以有无限个具现体，也就是说可以保存无限多种可能型别的函数或类似函数的东西(如，仿函数)。这个类(在Boost库中的类名为function)与函数指针相比应该有以下一些优势：
¨ 同一个function对象应能够接受与它形式兼容的所有函数和仿函数,例如：
int f1(int); //这是个函数，形式为 int(int)
short f2(double); //这个函数形式为 short(double)
strUCt functor //这是个仿函数类，形式为int(int)
{
int Operator()(int){}
};
functor f3; //创建仿函数对象
boost::function＜int(int)＞ func; // int(int)型的函数或仿函数
func = f1; //接受f1
func(10); //调用f1(10)
func = f2; //也能接受short(double)型的f2
func(10); //调用f2(10)
func = f3; //也能接受仿函数f3
func(10); //调用f3(10)
¨ function应能够和参数绑定以及其它function-construction库协同工作。例如，function应该也能够接受std::bind1st返回的仿函数。这一点其实由第一点已经有所保证。
¨ 当接受的一个空的仿函数对象被调用的时候function应该有可预期的行为。
显然，第一点是我们的重点，所谓形式兼容，就是说，对于：
R1 (T0,T1,T2,...,TN) =＞ FunctionType1
R2 (P0,P1,P2,...,PN) =＞ FunctionType2
两种类型的函数（广义），只要满足：
1. R2能够隐式转换为R1
2. 所有Ti都能够隐式转换为Pi (i取0,1,2,...)
那么就说，boost::function＜FunctionType1＞可以接受FunctionType2类型的函数(注重，反之不行)。支持这一论断的理由是，只要Ti能够隐式转型为Pi，那么参数被转发给真实的函数调用就是安全的，并且假如R2能够隐式转型为R1，那么返回真实函数调用所返回的值就是安全的。这里安全的含义是，C++类型系统认为隐式转换不会丢失信息，或者会给出编译警告，但能够通过编译。
后面你会看到，boost::function通过所谓的invoker非常巧妙地实现了这点，并且阻止了被形式不兼容的函数赋值的操作。
更多内容请看C/C++技术专题专题，或
探险
好吧，预备好，我们要出发了，进行深入源码世界的探险。
先看一个function的最简单的使用：
int g(int); //为了让代码简单，假设g有定义，以后的代码都会如此
function＜int(int)＞ f(g);
f(0);
间奏——R(T1,T2,...)函数类型
虽然这个间奏未免早了点儿，但是为了让你以后不会带着迷惑，这显然是必要的。请保持耐心。
或许你会对模板参数int(int)感到生疏，其实它是个函数型别——函数g的确切型别就是int(int)，而我们通常所看到的函数指针型别int (*)(int)则是&g的型别。它们的区别与联系在于：当把g作为一个值进行拷贝的时候（例如，按值传参），其类型就会由int(int)退化为int(*)(int)，即从函数类型退化为函数指针类型——因为从语义上说，函数不能被“按值拷贝”，但身为函数指针的地址值则是可以被拷贝的。另一方面，假如g被绑定到引用，则其类型不会退化，仍保持函数类型。例如：
template＜class T＞
void test_func_type(T ft) //按值传递，类型退化
{
static_cast＜int＞(ft); //引发编译错误，从而看出ft的类型为退化后的函数指针
}
int g(int); //函数g，名字g的类型为int(int)
test_func_type(g); //注重，并非&g，参数g的类型将会退化为函数指针类型
int (&ref_f)(int) = g; //注重，并非“= &g”，因为绑定到引用，类型并不退化
当然，这样的代码不能通过编译，因为static_cast＜＞显然不会让一个函数指针转换为int，然而我们就是要它通不过编译，这样我们才能窥视到按值传递的参数ft的类型到底是什么，从编译错误中我们看出，ft的类型是int(*)(int)，也就是说，在按值传递的过程中，g的类型退化为函数指针类型，变得和&g的类型一样了。而ref_t的类型则是引用，引用绑定则没有引起类型退化。
请注重，函数类型乃是个极其非凡的类型，在大多数时候它都会退化为函数指针类型，以便满足拷贝语义，只有面对引用绑定的时候，能够维持原来的类型。当然，对于boost::function，总是按值拷贝。
继续旅程
好吧，回过神来，我们还有更多地带要去探究。
function＜int(int)＞实际上进行了模板偏特化，Boost库给function的类声明为：
template＜typename Signature, //函数类型
typename Allocator = ...
＞ //Allocator并非重点，故不作介绍
class function;
事实上function类只是个薄薄的外覆（wrapper），真正起作用的是偏特化版本。
对于function＜R(T0)＞形式，偏特化版本的function源码像这样(实际上在boost源代码中你看不到模板参数T0的声明，也看不到function1，它们被宏替换掉了，那些精巧的宏是为了减小可见的代码量，至于它们的细节则又是一个世界，以下代码可看作对将那些令人眼花缭乱的宏展开后所得到的代码，具有更好的可读性)：
摘自：”boost/function/function_template.hpp”
template＜typename R,typename T0,typename Allocator＞
class function＜R(T0),Allocator＞ //对R(T0)函数类型的偏特化版本
:public function1＜R,T0,Allocator＞ //为R(T0)形式的函数预备的基类，在下面讨论
{
typedef function1＜R,T0,Allocator＞ base_type;
typedef function selftype;
struct clear_type{}; //马上你会看到这个蹊跷的类型定义的作用
public:
function() : base_type() {} //默认构造
template＜typename Functor＞ //模板化的构造函数，为了能够接受形式兼容的仿函数对象
function(Functor f, typename enable_if＜
(ice_not＜(is_same＜Functor, int＞::value)＞::value),
int
＞::type = 0) ：base_type(f){}
function(clear_type*) : base_type() {} //这个构造函数的作用在下面解释
self_type& operator=(const self_type& f) //同类型function对象之间应该能够赋值
{
self_type(f).swap(*this); //swap技巧，细节见《Effective STL》
return *this;
}
...
};
enable_if
你一定对模板构造函数中出现的那个冗长的enable_if＜...＞的作专心存迷惑，其实它的作用说穿了很简单，就是：当用户构造：
function＜int(int)＞ f(0);
的时候，将该（带有enable_if的）构造函数从重载决议的候选集中踢掉。使重载决议的结果为选中第三个构造函数：
function(clear_type*):base_type(){}
从而进行缺省构造。 而说得冗长一点就是：当f的类型——Functor——不是int时，该构造函数就是“有效（enable）”的，会被重载决议选中。但假如用户提供了一个0，用意是构造一个空(null)的函数指针，那么该函数就会由于“SFINAE”原则而被从重载决议的候选函数中踢掉。为什么要这样呢？因为该构造函数负责把确切的f保存起来，它假定f并非0。那应该选择谁呢？第三个构造函数！其参数类型是clear_type*，当然，0可以被赋给任何指针，所以它被选出，执行缺省的构造行为。 更多内容请看C/C++技术专题专题，或
基类 functionN
function的骨架就这些。也许你会问，function作为一个仿函数类，怎么没有重载operator()——这可是身为仿函数的标志啊！别急，function把这些烦人的任务都丢给了它的基类functionN，根据情况不同，N可能为0，1，2...，说具体一点就是：根据用户使用function时给出的函数类型，function将会继续自不同的基类——假如用户给出的函数类型为“R()”形式的，即仅有一个参数，则function继续自function0，而对于R(T0)形式的函数类型，则继续自function1，依此类推。前面说过，function只是一层外覆，而所有的秘密都在其基类functionN中！
不知道你有没有发现，function的骨架中也几乎没有用到函数类型的信息，事实上，它也将这些信息一股脑儿抛给了基类。在这过程中，混沌一团的int(int)型别被拆解为两个单独的模板参数传给基类:
template＜typename R,typename T0,typename Allocator＞
class function＜R(T0),Allocator＞ //R(T0)整个为一型别
:public function1＜R,T0,Allocator＞ //拆解为两个模板参数R,T0传给基类
好了，下面我们深入基类function1。真正丰富的宝藏在里面。
function1
function1的源代码像这样(与上面一样，事实上有些代码你是看不到的，为了不让你迷惑，我给出的是将宏展开后得到的代码):
摘自：”boost/function/function_template.hpp”
template＜typename R,typename T0,class Allocator = ...＞
class function1:public function_base //function_base负责治理内存
{
...
public:
typedef R result_type; //返回类型
typedef function1 self_type;
function1() : function_base(),invoker(0){}//默认构造
template＜typename Functor＞
function1(Functor const & f, //模板构造函数
typename enable_if＜...＞::type = 0) :
function_base(),
invoker(0)
{
this-＞assign_to(f); //这儿真正进行赋值，assign_to的代码在下面列出
}
function1(clear_type*) : function_base(), invoker(0){} //该构造函数上面解释过
function1(const function& f) : //拷贝构造函数
function_base(),
invoker(0){
this-＞assign_to_own(f); //专用于在function之间赋值的assignment
}
result_type operator()(T0 a0) const //身为仿函数的标志！
{
//下面负责调用指向的函数
if (this-＞empty())
boost::throw_exception(bad_function_call());
//这里进行真正的函数调用，使用invoker
internal_result_type result = invoker(function_base::functor,a0);
return static_cast＜result_type＞(result);
}
template＜typename Functor＞
void assign_to(Functor f) //所有的构造函数都调用它！具有多个重载版本。
{
//以一个get_function_tag萃取出Functor的类别(category)!
typedef typename detail::function::get_function_tag＜Functor＞::type tag;
this-＞assign_to(f, tag());//根据不同类别的Functor采取不同的assign策略！
}
get_function_tag＜＞能萃取出Functor的类别(category)，有下面几种类别
struct function_ptr_tag {}; //函数指针类别
struct function_obj_tag {}; //仿函数对象类别
struct member_ptr_tag {}; //成员函数类别
struct function_obj_ref_tag {};//以ref(obj)加以封装的类别，具有引用语义
struct stateless_function_obj_tag {}; //无状态函数对象
满足以下所有条件：
has_trivial_constructor
has_trivial_copy
has_trivial_destructor
is_empty
的仿函数对象称为stateless的
而对于不同的函数类别，assign_to有各个不同的重载版本，如下：
template＜typename FunctionPtr＞ //假如是函数指针就调用这个版本
void assign_to(FunctionPtr f, function_ptr_tag) //这个版本针对函数指针
{
clear();
if (f){
typedef typename detail::function::get_function_invoker1＜FunctionPtr,R,T0＞::type invoker_type;
invoker = &invoker_type::invoke; //invoke是static成员函数
function_base::manager = //治理策略
&detail::function::functor_manager＜FunctionPtr, Allocator＞::manage;
function_base::functor = //交给function的函数指针或仿函数对象指针最终在这儿保存
function_base::manager(
detail::function::make_any_pointer((void (*)())(f)),
detail::function::clone_functor_tag);//实际上拷贝了一份函数指针
}
}
...
typedef internal_result_type (*invoker_type)(detail::function::any_pointer,T0);
invoker_type invoker; //重要成员，负责调用函数！
};
你可能已经被这段“夹叙夹议”的代码弄得头昏脑涨了，但这才刚刚开始！
function的底层存储机制
请将目光转向上面的代码段末尾的assign_to函数中，其中有两行深色的代码，分别对function_base里的manager和functor成员赋值。这两行代码肩负了保存各种函数指针的任务。
manager是一个函数指针，它所指向的函数代表治理策略，例如，对于函数指针，仅仅作一次赋值，就保存完毕了，但是对于仿函数，得额外分配一次内存，然后将仿函数拷贝到分配的内存中，这才完成了保存的任务。这些策略根据函数的类别而定，上面代码中的assign_to函数是针对函数指针类别的重载版本，所以manager的策略是不作任何内存分配，直接返回被转型为“void(*)()”（利于在底层以统一的形式保存）的函数指针就行了，这从代码中可以看出。
需要说明的是，对于函数指针，function_base并不知道也不关心它要保存的函数指针是什么确切的类型，只要是函数指针就行，因为它总会把该函数指针f转型为“void (*)()”类型，然后保存在functor成员中，functor成员是一个union:
union any_pointer
{
void* obj_ptr; //任意仿函数对象指针都可以用static_cast＜＞转型为void*型
const void* const_obj_ptr; //为const仿函数预备的
void (*func_ptr)(); //任意函数指针都可以用reinterPRet_cast＜＞转型为void(*)()型
char data[1];
};
这个any_pointer可以通过安全转型保存所有形式的仿函数和函数指针，承载在底层保存数据的任务
function的调用机制——invoker
我们把目光转到function1的定义的最底部，那儿定义了它最重要的成员invoker，它是一个函数指针，所指向的函数就是function的调用机制所在，invoker的类型为：
typedef internal_result_type (*invoker_type)(any_pointer,T0);
前面已经说过，any_pointer是个union，可以保存任何类型的函数指针或函数对象，里面保存的是用户注册的函数或仿函数，T0为调用any_pointer中的函数的参数的型别（对于不同情况，可能会有T1,T2等）。这也就是说，invoker负责调用保存在any_pointer中的用户提供的函数或仿函数。
那么，invoker这个函数指针到底指向什么函数呢——也就是说，在什么时候invoker被赋值了呢？我们再次把目光转向assign_to函数，其中有一行对invoker成员赋值的语句，从这行语句出发我们可以揭露invoker的全部奥秘：
invoker = &invoker_type::invoke; //invoke是static成员函数
请不要把这个invoker_type和上面那个函数指针型别invoker_type混淆起来，这个invoker_type是位于assign_to函数中的一个局部的typedef，所以隐藏了后者（即类作用域中的那个invoker_type——invoker成员的类型）。往上一行，你就看到这个局部型别invoker_type的定义了：
typedef typename get_function_invoker1＜
FunctionPtr,R,T0＞::type invoker_type;
get_function_invoker1又是何物？很显然，这是个traits，其内嵌的::type会根据不同的模板参数表现为不同的类型，在本例中，::type的类型将会被推导为
function_invoker1＜int(*)(int),int,int＞
而function_invoker1是个类模板，其定义为：
template＜typename FunctionPtr,
typename R，typename T0＞ //注重这里的模板参数，后面会解释
struct function_invoker1
{
static R invoke(any_pointer function_ptr,T0 a0)
{
FunctionPtr f = reinterpret_cast＜FunctionPtr＞(function_ptr.func_ptr);
return f(a0);
}
};
所以对invoker的赋值最终相当于：
invoker=&function_invoker1＜int(*)(int),int,int＞::invoke;
而function_invoker1＜int(*)(int),int,int＞::invoke是静态成员函数，它被实例化后相当于：
static int invoke(any_pointer function_ptr,int a0)
{
//先转型，再调用，注重，这一行语句还有一个额外的作用，在后面解释
int (*f)(int) = reinterpret_cast＜int(*)(int)＞(function_ptr.func_ptr);
//因为f指向的是用户保存在该function中的函数或仿函数，所以这一行语句进行了真实的调用！
return f(a0);
}
我们可以看出，在invoke函数中，真正的调用现身了。
假如接受的是仿函数，则有function_obj_invoker1与它对应，后者也是一个类似的模板，它的invoke静态成员函数的形式也是：
static R invoke(any_pointer function_obj_ptr,T0 a0);
其中function_obj_ptr是指向仿函数的指针，所以其invoke静态成员函数中对它的调用语句是这样的：
FunctionObj* f = (FunctionObj*)(function_obj_ptr.obj_ptr);
return (*f)(a0); //调用用户的仿函数
最后一种可能：假如接受的是成员函数怎么办呢？简单的答案是：boost::function并没有为成员函数作任何非凡预备！理由也很简单，boost::function只要先将成员函数封装为仿函数，然后将其作为一般的仿函数对待就行了，具体代码就不列了，STL中有一个函数模板std::mem_fun就是用于封装成员函数指针的，它返回的是一个仿函数。boost中也对该函数模板做了扩充，使它可以接受任意多个参数的成员函数。 更多内容请看C/C++技术专题专题，或
做一个，送一个——invoker的额外好处
我们注重到function的构造和赋值函数及其基类的构造和赋值函数都是模板函数，这是因为用户可能提供函数也可能提供函数模板，但最要害的还是，functiont提供一种能力：对于function＜double(int)＞类型的泛型函数指针，用户可以给它一个int(int)类型的函数——是的，这是可行且安全的，因为其返回值类型int可以安全的转型为double，而对于这种类型兼容性的检查就在上面分析的invoke静态成员函数中，这就是我们要说的额外好处——假如类型兼容，那么invoke函数就能正常编译通过，但假如用户给出类型不兼容的函数，就会得到一个错误，这个错误是在编译器实例化invoke函数代码的时候给出的，例如，用户假如这样写：
RT1 f(P1,P2); // RT1(P1,P2)函数类型，这里的RT1,P1,P2假定已经定义，这是一般化的符号
function＜RT(P)＞ f_ptr; //RT(P)函数类型，同样假定RT,P已定义
f_ptr = &f; //类型不兼容，错误！
这就会导致编译错误，错误发生在invoke静态成员函数中。下面我就为你解释为什么。
我想你对function_invoker1考的三个模板参数仍然心存迷惑，我们再一次往返顾一下其声明：
template＜typename FunctionPtr,typename R，typename T0＞
struct function_invoker1
我们还得把目光投向assign_to模板函数，其中使用function_invoker1的时候是这样的：
typedef typename detail::function::get_function_invoker1＜
FunctionPtr,R,T0＞::type invoker_type;
这里，给出的FunctionPtr,R,T0三个模板参数将会原封不动的传给function_invoker1，那么对于我们上面的错误示例，这三个模板参数各是什么呢？
首先，我们很轻易看出，FunctionPtr就是assign_to模板函数的模板参数，也就是用户传递的函数或仿函数的类型，在我们的错误示例中，函数f的类型为RT1(P1,P2)，所以
FunctionPtr = RT1(*)(P1,P2)
而R,T0则是用户在实例化function模板时给出的模板参数，我们写的是function＜RT(P)＞，于是:
R = RT
T0 = P
所以，对于我们的错误示例，invoker_type的类型为：
function_invoker1＜ RT1(*)(P1,P2),RT,P＞
对于这样一个function_invoker1，其内部的invoke静态成员函数被实例化为：
static RT invoke(any_pointer function_ptr,P a0)
{
RT1 (*f)(P1,P2)= //FunctorPtr f =reinterpret_cast＜RT1(*)(P1,P2)＞(function_ptr.func_ptr);
return f(a0); //错啦！瞧瞧f的型别，f接受一个P类型的参数吗？编译器在此打住。
//这行语句的另一个隐含的检查是返回值类型匹配，f(...)返回RT1，而invoke须得返回RT
}
看看最后一行语句，所有的检查都在那里了——我们最终把检查“委托”给了C++底层的类型系统。
很精妙不是吗？虽然在模板形式的assign_to函数中，看起来我们并不关心到底用户给的参数是何类型，看起来用户可以把任何函数或仿函数塞过来，但是一旦下面触及invoker的赋值，就得实例化invoke静态成员函数，其中的：
return f(a0);
一下就把问题暴露出来了！这种把类型检查延迟到最后，不得不进行的时候，由C++底层的类型系统来负责检查的手法的确很奇妙——看起来我们没有在assign_to函数中及时利用类型信息进行类型检查，但是我们却并没有丧失任何类型安全性，一切最终都逃不过C++底层的类型系统的考验！
function如何对待成员函数
对于成员函数，assign_to的重载版本只有一行：
this-＞assign_to(mem_fn(f));
mem_fun(f)返回一个仿函数，它封装了成员函数f，之后一切皆与仿函数无异。
关于mem_fun的细节，这里就不多说了，大家可以参考STL中的实现，相信很轻易看懂，这里只简单的提醒一下，成员函数封装的效果是这样的：
R (C::*)(T0,T1,...) --＞ R (*)(C*,T0,T1,...) 或 R (*)(C&,T0,T1,...)
safe_bool惯用手法
如你所知，对于函数指针fptr，我们可以这样测试它：if(fptr) ...，所以function也应该提供这一特性，然而假如直接重载operator bool()则会导致下面的代码成为合法的:
function＜int(int)＞ f;
bool b=f;
这显然不妥，所以function用另一个巧妙的手法替代它，既所谓的safe_bool惯用手法，这在function定义内部的源码如下：
struct dummy { void nonnull(){};};
typedef void (dummy::*safe_bool)(); //确保safebool不能转型为任何其它类型！
operator safe_bool () const
{ return (this-＞empty())? 0 : &dummy::nonnull; }
这样，当你写if(f)的时候，编译器会找到operator safe_bool()，从而将f转型为safe_bool，这是个指针类型，if语句会正确判定它是否为空。而当你试图把f赋给其它类型的变量的时候则会遭到编译期的拒绝——因为safe_bool无法向其它类型转换。
get_function_tag＜＞
get_function_tag＜＞用于萃取出函数所属类别(category)，各个类别在源代码中已经列出，至于它到底是如何萃取的，这与本文关系不是很 大，有一点需要提醒一下：函数指针类型也是指针类型，这听起来完全是句废话，但是考虑这样的代码：
template＜typename T＞ struct is_pointer{enum{value=0};};
template＜typename T＞ struct is_pointer＜T*＞{enum{value=1};};
std::cout＜＜is_pointer＜int(*)(int)＞::value; //这将输出 1
也就是说int(*)(int)可以与T*形式匹配，匹配时T为int(int)。
最后一些细节
1. 我没有给出function_base的源代码，实际上那很简单，它最主要的成员就是union any_pointer型的数据成员
detail::function::any_pointer functor; //用于统一保存函数指针及仿函数对象指针
2. 我没有给出functor_manager的信息，实际上它与function的实现没有太大关系，它负责copy和delete函数对象，假如必要的话。所以我将它略去，它的源码在：”boost/function/function_base.hpp”里。
3. 我给出的源代码是将宏展开后的版本，实际的代码中充斥着让人眼花缭乱的宏，关于那些宏则又是一个奇妙的世界。Boost库通过那些宏省去了许多可见代码量。随着函数参数的不同，那些宏会扩展出function2,function3...各个版本。
本文只研究了int(int)型的情况，其它只是参数数目的改变而已。经过宏的扩展，function的偏特化版本将有:
template＜typename R,typename Allocator＞
class function＜R(),Allocator＞:public function0＜R,Allocator＞
{...};
template＜typename R,typename T0,typename Allocator＞
class function＜R(T0),Allocator＞:public function1＜R,T0,Allocator＞
{...};
template＜typename R,typename T0,typename T1,typename Allocator＞
class function＜R(T0,T1),Allocator＞:public function2＜R,T0,T1,Allocator＞
{...};
等更多版本，一共有BOOST_FUNCTION_MAX_ARGS+1个版本，BOOST_FUNCTION_MAX_ARGS为一个宏，表示最多能够接受有多少个参数的函数及仿函数对象，你可以重新定义这个宏为一个新值，以控制function所能支持的函数参数个数的最大值。其中的function0,function1,function2等名字也由宏扩展出。 更多内容请看C/C++技术专题专题，或
如你所知，Boost库是个特性完备，且具备工业强度的库，众多C++权威的参与使其达到了登峰造极的程度。尤其泛型的强大威力在其中被发挥得淋漓尽致，令人瞠目结舌。
然而弱水三千，我们只取一瓢饮。下面，我试图从最单纯的世界开始，一步一步带领你进入源码的世界，去探究boost::function(下文简称function)内部的精微结构。
通常 ，在单纯的情况下，对函数的调用简单而且直观，像这样：
int fun(int someVal);
int main(){
fun(10);
}
然而你可能需要在某个时刻将函数指针保存下来，并在以后的另一个时刻调用它，像这样：
int fun(int);
typedef int (*func_handle)(int);
int main(){
func_handle fh=fun;
... //do something
fh(10);
}
但是，假如fun形式为void fun(int)呢？如你所见，fun可能有无数种形式，假如对fun的每一个形式都typedef一个对应的func_handle，则程序员会焦头烂额，不胜其扰，代码也可能变得臃肿和丑陋不堪，甚至假如fun是仿函数呢？
幸运的是C++泛型可以使代码变得优雅精致，面对无数种的可能，泛型是最好的选择。 因此，你只是需要一个能够保存函数指针的泛型模板类(对应于Command模式)，因为泛型编程有一个先天性的优势——可以借助编译器的力量在编译期根据用户提供的型别信息化身千万(具现化)，所以一个泛型的类可以有无限个具现体，也就是说可以保存无限多种可能型别的函数或类似函数的东西(如，仿函数)。这个类(在Boost库中的类名为function)与函数指针相比应该有以下一些优势：
¨ 同一个function对象应能够接受与它形式兼容的所有函数和仿函数,例如：
int f1(int); //这是个函数，形式为 int(int)
short f2(double); //这个函数形式为 short(double)
strUCt functor //这是个仿函数类，形式为int(int)
{
int Operator()(int){}
};
functor f3; //创建仿函数对象
boost::function＜int(int)＞ func; // int(int)型的函数或仿函数
func = f1; //接受f1
func(10); //调用f1(10)
func = f2; //也能接受short(double)型的f2
func(10); //调用f2(10)
func = f3; //也能接受仿函数f3
func(10); //调用f3(10)
¨ function应能够和参数绑定以及其它function-construction库协同工作。例如，function应该也能够接受std::bind1st返回的仿函数。这一点其实由第一点已经有所保证。
¨ 当接受的一个空的仿函数对象被调用的时候function应该有可预期的行为。
显然，第一点是我们的重点，所谓形式兼容，就是说，对于：
R1 (T0,T1,T2,...,TN) =＞ FunctionType1
R2 (P0,P1,P2,...,PN) =＞ FunctionType2
两种类型的函数（广义），只要满足：
1. R2能够隐式转换为R1
2. 所有Ti都能够隐式转换为Pi (i取0,1,2,...)
那么就说，boost::function＜FunctionType1＞可以接受FunctionType2类型的函数(注重，反之不行)。支持这一论断的理由是，只要Ti能够隐式转型为Pi，那么参数被转发给真实的函数调用就是安全的，并且假如R2能够隐式转型为R1，那么返回真实函数调用所返回的值就是安全的。这里安全的含义是，C++类型系统认为隐式转换不会丢失信息，或者会给出编译警告，但能够通过编译。
后面你会看到，boost::function通过所谓的invoker非常巧妙地实现了这点，并且阻止了被形式不兼容的函数赋值的操作。
更多内容请看C/C++技术专题专题，或
探险好吧，预备好，我们要出发了，进行深入源码世界的探险。
先看一个function的最简单的使用：
int g(int); //为了让代码简单，假设g有定义，以后的代码都会如此
function＜int(int)＞ f(g);
f(0);
间奏——R(T1,T2,...)函数类型
虽然这个间奏未免早了点儿，但是为了让你以后不会带着迷惑，这显然是必要的。请保持耐心。
或许你会对模板参数int(int)感到生疏，其实它是个函数型别——函数g的确切型别就是int(int)，而我们通常所看到的函数指针型别int (*)(int)则是&g的型别。它们的区别与联系在于：当把g作为一个值进行拷贝的时候（例如，按值传参），其类型就会由int(int)退化为int(*)(int)，即从函数类型退化为函数指针类型——因为从语义上说，函数不能被“按值拷贝”，但身为函数指针的地址值则是可以被拷贝的。另一方面，假如g被绑定到引用，则其类型不会退化，仍保持函数类型。例如：
template＜class T＞
void test_func_type(T ft) //按值传递，类型退化
{
static_cast＜int＞(ft); //引发编译错误，从而看出ft的类型为退化后的函数指针
}
int g(int); //函数g，名字g的类型为int(int)
test_func_type(g); //注重，并非&g，参数g的类型将会退化为函数指针类型
int (&ref_f)(int) = g; //注重，并非“= &g”，因为绑定到引用，类型并不退化
当然，这样的代码不能通过编译，因为static_cast＜＞显然不会让一个函数指针转换为int，然而我们就是要它通不过编译，这样我们才能窥视到按值传递的参数ft的类型到底是什么，从编译错误中我们看出，ft的类型是int(*)(int)，也就是说，在按值传递的过程中，g的类型退化为函数指针类型，变得和&g的类型一样了。而ref_t的类型则是引用，引用绑定则没有引起类型退化。
请注重，函数类型乃是个极其非凡的类型，在大多数时候它都会退化为函数指针类型，以便满足拷贝语义，只有面对引用绑定的时候，能够维持原来的类型。当然，对于boost::function，总是按值拷贝。
继续旅程
好吧，回过神来，我们还有更多地带要去探究。
function＜int(int)＞实际上进行了模板偏特化，Boost库给function的类声明为：
template＜typename Signature, //函数类型
typename Allocator = ...
＞ //Allocator并非重点，故不作介绍
class function;
事实上function类只是个薄薄的外覆（wrapper），真正起作用的是偏特化版本。
对于function＜R(T0)＞形式，偏特化版本的function源码像这样(实际上在boost源代码中你看不到模板参数T0的声明，也看不到function1，它们被宏替换掉了，那些精巧的宏是为了减小可见的代码量，至于它们的细节则又是一个世界，以下代码可看作对将那些令人眼花缭乱的宏展开后所得到的代码，具有更好的可读性)：
摘自：”boost/function/function_template.hpp”
template＜typename R,typename T0,typename Allocator＞
class function＜R(T0),Allocator＞ //对R(T0)函数类型的偏特化版本
:public function1＜R,T0,Allocator＞ //为R(T0)形式的函数预备的基类，在下面讨论
{
typedef function1＜R,T0,Allocator＞ base_type;
typedef function selftype;
struct clear_type{}; //马上你会看到这个蹊跷的类型定义的作用
public:
function() : base_type() {} //默认构造
template＜typename Functor＞ //模板化的构造函数，为了能够接受形式兼容的仿函数对象
function(Functor f, typename enable_if＜
(ice_not＜(is_same＜Functor, int＞::value)＞::value),
int
＞::type = 0) ：base_type(f){}
function(clear_type*) : base_type() {} //这个构造函数的作用在下面解释
self_type& operator=(const self_type& f) //同类型function对象之间应该能够赋值
{
self_type(f).swap(*this); //swap技巧，细节见《Effective STL》
return *this;
}
...
};
enable_if
你一定对模板构造函数中出现的那个冗长的enable_if＜...＞的作专心存迷惑，其实它的作用说穿了很简单，就是：当用户构造：
function＜int(int)＞ f(0);
的时候，将该（带有enable_if的）构造函数从重载决议的候选集中踢掉。使重载决议的结果为选中第三个构造函数：
function(clear_type*):base_type(){}
从而进行缺省构造。 而说得冗长一点就是：当f的类型——Functor——不是int时，该构造函数就是“有效（enable）”的，会被重载决议选中。但假如用户提供了一个0，用意是构造一个空(null)的函数指针，那么该函数就会由于“SFINAE”原则而被从重载决议的候选函数中踢掉。为什么要这样呢？因为该构造函数负责把确切的f保存起来，它假定f并非0。那应该选择谁呢？第三个构造函数！其参数类型是clear_type*，当然，0可以被赋给任何指针，所以它被选出，执行缺省的构造行为。
更多内容请看C/C++技术专题专题，或
基类 functionNfunction的骨架就这些。也许你会问，function作为一个仿函数类，怎么没有重载operator()——这可是身为仿函数的标志啊！别急，function把这些烦人的任务都丢给了它的基类functionN，根据情况不同，N可能为0，1，2...，说具体一点就是：根据用户使用function时给出的函数类型，function将会继续自不同的基类——假如用户给出的函数类型为“R()”形式的，即仅有一个参数，则function继续自function0，而对于R(T0)形式的函数类型，则继续自function1，依此类推。前面说过，function只是一层外覆，而所有的秘密都在其基类functionN中！
不知道你有没有发现，function的骨架中也几乎没有用到函数类型的信息，事实上，它也将这些信息一股脑儿抛给了基类。在这过程中，混沌一团的int(int)型别被拆解为两个单独的模板参数传给基类:
template＜typename R,typename T0,typename Allocator＞
class function＜R(T0),Allocator＞ //R(T0)整个为一型别
:public function1＜R,T0,Allocator＞ //拆解为两个模板参数R,T0传给基类
好了，下面我们深入基类function1。真正丰富的宝藏在里面。
function1
function1的源代码像这样(与上面一样，事实上有些代码你是看不到的，为了不让你迷惑，我给出的是将宏展开后得到的代码):
摘自：”boost/function/function_template.hpp”
template＜typename R,typename T0,class Allocator = ...＞
class function1:public function_base //function_base负责治理内存
{
...
public:
typedef R result_type; //返回类型
typedef function1 self_type;
function1() : function_base(),invoker(0){}//默认构造
template＜typename Functor＞
function1(Functor const & f, //模板构造函数
typename enable_if＜...＞::type = 0) :
function_base(),
invoker(0)
{
this-＞assign_to(f); //这儿真正进行赋值，assign_to的代码在下面列出
}
function1(clear_type*) : function_base(), invoker(0){} //该构造函数上面解释过
function1(const function& f) : //拷贝构造函数
function_base(),
invoker(0){
this-＞assign_to_own(f); //专用于在function之间赋值的assignment
}
result_type operator()(T0 a0) const //身为仿函数的标志！
{
//下面负责调用指向的函数
if (this-＞empty())
boost::throw_exception(bad_function_call());
//这里进行真正的函数调用，使用invoker
internal_result_type result = invoker(function_base::functor,a0);
return static_cast＜result_type＞(result);
}
template＜typename Functor＞
void assign_to(Functor f) //所有的构造函数都调用它！具有多个重载版本。
{
//以一个get_function_tag萃取出Functor的类别(category)!
typedef typename detail::function::get_function_tag＜Functor＞::type tag;
this-＞assign_to(f, tag());//根据不同类别的Functor采取不同的assign策略！
}
get_function_tag＜＞能萃取出Functor的类别(category)，有下面几种类别
struct function_ptr_tag {}; //函数指针类别
struct function_obj_tag {}; //仿函数对象类别
struct member_ptr_tag {}; //成员函数类别
struct function_obj_ref_tag {};//以ref(obj)加以封装的类别，具有引用语义
struct stateless_function_obj_tag {}; //无状态函数对象
满足以下所有条件：
has_trivial_constructor
has_trivial_copy
has_trivial_destructor
is_empty
的仿函数对象称为stateless的
而对于不同的函数类别，assign_to有各个不同的重载版本，如下：
template＜typename FunctionPtr＞ //假如是函数指针就调用这个版本
void assign_to(FunctionPtr f, function_ptr_tag) //这个版本针对函数指针
{
clear();
if (f){
typedef typename detail::function::get_function_invoker1＜FunctionPtr,R,T0＞::type invoker_type;
invoker = &invoker_type::invoke; //invoke是static成员函数
function_base::manager = //治理策略
&detail::function::functor_manager＜FunctionPtr, Allocator＞::manage;
function_base::functor = //交给function的函数指针或仿函数对象指针最终在这儿保存
function_base::manager(
detail::function::make_any_pointer((void (*)())(f)),
detail::function::clone_functor_tag);//实际上拷贝了一份函数指针
}
}
...
typedef internal_result_type (*invoker_type)(detail::function::any_pointer,T0);
invoker_type invoker; //重要成员，负责调用函数！
};
你可能已经被这段“夹叙夹议”的代码弄得头昏脑涨了，但这才刚刚开始！
function的底层存储机制
请将目光转向上面的代码段末尾的assign_to函数中，其中有两行深色的代码，分别对function_base里的manager和functor成员赋值。这两行代码肩负了保存各种函数指针的任务。
manager是一个函数指针，它所指向的函数代表治理策略，例如，对于函数指针，仅仅作一次赋值，就保存完毕了，但是对于仿函数，得额外分配一次内存，然后将仿函数拷贝到分配的内存中，这才完成了保存的任务。这些策略根据函数的类别而定，上面代码中的assign_to函数是针对函数指针类别的重载版本，所以manager的策略是不作任何内存分配，直接返回被转型为“void(*)()”（利于在底层以统一的形式保存）的函数指针就行了，这从代码中可以看出。
需要说明的是，对于函数指针，function_base并不知道也不关心它要保存的函数指针是什么确切的类型，只要是函数指针就行，因为它总会把该函数指针f转型为“void (*)()”类型，然后保存在functor成员中，functor成员是一个union:
union any_pointer
{
void* obj_ptr; //任意仿函数对象指针都可以用static_cast＜＞转型为void*型
const void* const_obj_ptr; //为const仿函数预备的
void (*func_ptr)(); //任意函数指针都可以用reinterPRet_cast＜＞转型为void(*)()型
char data[1];
};
这个any_pointer可以通过安全转型保存所有形式的仿函数和函数指针，承载在底层保存数据的任务
function的调用机制——invoker
我们把目光转到function1的定义的最底部，那儿定义了它最重要的成员invoker，它是一个函数指针，所指向的函数就是function的调用机制所在，invoker的类型为：
typedef internal_result_type (*invoker_type)(any_pointer,T0);
前面已经说过，any_pointer是个union，可以保存任何类型的函数指针或函数对象，里面保存的是用户注册的函数或仿函数，T0为调用any_pointer中的函数的参数的型别（对于不同情况，可能会有T1,T2等）。这也就是说，invoker负责调用保存在any_pointer中的用户提供的函数或仿函数。
那么，invoker这个函数指针到底指向什么函数呢——也就是说，在什么时候invoker被赋值了呢？我们再次把目光转向assign_to函数，其中有一行对invoker成员赋值的语句，从这行语句出发我们可以揭露invoker的全部奥秘：
invoker = &invoker_type::invoke; //invoke是static成员函数
请不要把这个invoker_type和上面那个函数指针型别invoker_type混淆起来，这个invoker_type是位于assign_to函数中的一个局部的typedef，所以隐藏了后者（即类作用域中的那个invoker_type——invoker成员的类型）。往上一行，你就看到这个局部型别invoker_type的定义了：
typedef typename get_function_invoker1＜
FunctionPtr,R,T0＞::type invoker_type;
get_function_invoker1又是何物？很显然，这是个traits，其内嵌的::type会根据不同的模板参数表现为不同的类型，在本例中，::type的类型将会被推导为
function_invoker1＜int(*)(int),int,int＞
而function_invoker1是个类模板，其定义为：
template＜typename FunctionPtr,
typename R，typename T0＞ //注重这里的模板参数，后面会解释
struct function_invoker1
{
static R invoke(any_pointer function_ptr,T0 a0)
{
FunctionPtr f = reinterpret_cast＜FunctionPtr＞(function_ptr.func_ptr);
return f(a0);
}
};
所以对invoker的赋值最终相当于：
invoker=&function_invoker1＜int(*)(int),int,int＞::invoke;
而function_invoker1＜int(*)(int),int,int＞::invoke是静态成员函数，它被实例化后相当于：
static int invoke(any_pointer function_ptr,int a0)
{
//先转型，再调用，注重，这一行语句还有一个额外的作用，在后面解释
int (*f)(int) = reinterpret_cast＜int(*)(int)＞(function_ptr.func_ptr);
//因为f指向的是用户保存在该function中的函数或仿函数，所以这一行语句进行了真实的调用！
return f(a0);
}
我们可以看出，在invoke函数中，真正的调用现身了。
假如接受的是仿函数，则有function_obj_invoker1与它对应，后者也是一个类似的模板，它的invoke静态成员函数的形式也是：
static R invoke(any_pointer function_obj_ptr,T0 a0);
其中function_obj_ptr是指向仿函数的指针，所以其invoke静态成员函数中对它的调用语句是这样的：
FunctionObj* f = (FunctionObj*)(function_obj_ptr.obj_ptr);
return (*f)(a0); //调用用户的仿函数
最后一种可能：假如接受的是成员函数怎么办呢？简单的答案是：boost::function并没有为成员函数作任何非凡预备！理由也很简单，boost::function只要先将成员函数封装为仿函数，然后将其作为一般的仿函数对待就行了，具体代码就不列了，STL中有一个函数模板std::mem_fun就是用于封装成员函数指针的，它返回的是一个仿函数。boost中也对该函数模板做了扩充，使它可以接受任意多个参数的成员函数。
更多内容请看C/C++技术专题专题，或
做一个，送一个——invoker的额外好处我们注重到function的构造和赋值函数及其基类的构造和赋值函数都是模板函数，这是因为用户可能提供函数也可能提供函数模板，但最要害的还是，functiont提供一种能力：对于function＜double(int)＞类型的泛型函数指针，用户可以给它一个int(int)类型的函数——是的，这是可行且安全的，因为其返回值类型int可以安全的转型为double，而对于这种类型兼容性的检查就在上面分析的invoke静态成员函数中，这就是我们要说的额外好处——假如类型兼容，那么invoke函数就能正常编译通过，但假如用户给出类型不兼容的函数，就会得到一个错误，这个错误是在编译器实例化invoke函数代码的时候给出的，例如，用户假如这样写：
RT1 f(P1,P2); // RT1(P1,P2)函数类型，这里的RT1,P1,P2假定已经定义，这是一般化的符号
function＜RT(P)＞ f_ptr; //RT(P)函数类型，同样假定RT,P已定义
f_ptr = &f; //类型不兼容，错误！
这就会导致编译错误，错误发生在invoke静态成员函数中。下面我就为你解释为什么。
我想你对function_invoker1考的三个模板参数仍然心存迷惑，我们再一次往返顾一下其声明：
template＜typename FunctionPtr,typename R，typename T0＞
struct function_invoker1
我们还得把目光投向assign_to模板函数，其中使用function_invoker1的时候是这样的：
typedef typename detail::function::get_function_invoker1＜
FunctionPtr,R,T0＞::type invoker_type;
这里，给出的FunctionPtr,R,T0三个模板参数将会原封不动的传给function_invoker1，那么对于我们上面的错误示例，这三个模板参数各是什么呢？
首先，我们很轻易看出，FunctionPtr就是assign_to模板函数的模板参数，也就是用户传递的函数或仿函数的类型，在我们的错误示例中，函数f的类型为RT1(P1,P2)，所以
FunctionPtr = RT1(*)(P1,P2)
而R,T0则是用户在实例化function模板时给出的模板参数，我们写的是function＜RT(P)＞，于是:
R = RT
T0 = P
所以，对于我们的错误示例，invoker_type的类型为：
function_invoker1＜ RT1(*)(P1,P2),RT,P＞
对于这样一个function_invoker1，其内部的invoke静态成员函数被实例化为：
static RT invoke(any_pointer function_ptr,P a0)
{
RT1 (*f)(P1,P2)= //FunctorPtr f =reinterpret_cast＜RT1(*)(P1,P2)＞(function_ptr.func_ptr);
return f(a0); //错啦！瞧瞧f的型别，f接受一个P类型的参数吗？编译器在此打住。
//这行语句的另一个隐含的检查是返回值类型匹配，f(...)返回RT1，而invoke须得返回RT
}
看看最后一行语句，所有的检查都在那里了——我们最终把检查“委托”给了C++底层的类型系统。
很精妙不是吗？虽然在模板形式的assign_to函数中，看起来我们并不关心到底用户给的参数是何类型，看起来用户可以把任何函数或仿函数塞过来，但是一旦下面触及invoker的赋值，就得实例化invoke静态成员函数，其中的：
return f(a0);
一下就把问题暴露出来了！这种把类型检查延迟到最后，不得不进行的时候，由C++底层的类型系统来负责检查的手法的确很奇妙——看起来我们没有在assign_to函数中及时利用类型信息进行类型检查，但是我们却并没有丧失任何类型安全性，一切最终都逃不过C++底层的类型系统的考验！
function如何对待成员函数
对于成员函数，assign_to的重载版本只有一行：
this-＞assign_to(mem_fn(f));
mem_fun(f)返回一个仿函数，它封装了成员函数f，之后一切皆与仿函数无异。
关于mem_fun的细节，这里就不多说了，大家可以参考STL中的实现，相信很轻易看懂，这里只简单的提醒一下，成员函数封装的效果是这样的：
R (C::*)(T0,T1,...) --＞ R (*)(C*,T0,T1,...) 或 R (*)(C&,T0,T1,...)
safe_bool惯用手法
如你所知，对于函数指针fptr，我们可以这样测试它：if(fptr) ...，所以function也应该提供这一特性，然而假如直接重载operator bool()则会导致下面的代码成为合法的:
function＜int(int)＞ f;
bool b=f;
这显然不妥，所以function用另一个巧妙的手法替代它，既所谓的safe_bool惯用手法，这在function定义内部的源码如下：
struct dummy { void nonnull(){};};
typedef void (dummy::*safe_bool)(); //确保safebool不能转型为任何其它类型！
operator safe_bool () const
{ return (this-＞empty())? 0 : &dummy::nonnull; }
这样，当你写if(f)的时候，编译器会找到operator safe_bool()，从而将f转型为safe_bool，这是个指针类型，if语句会正确判定它是否为空。而当你试图把f赋给其它类型的变量的时候则会遭到编译期的拒绝——因为safe_bool无法向其它类型转换。
get_function_tag＜＞
get_function_tag＜＞用于萃取出函数所属类别(category)，各个类别在源代码中已经列出，至于它到底是如何萃取的，这与本文关系不是很 大，有一点需要提醒一下：函数指针类型也是指针类型，这听起来完全是句废话，但是考虑这样的代码：
template＜typename T＞ struct is_pointer{enum{value=0};};
template＜typename T＞ struct is_pointer＜T*＞{enum{value=1};};
std::cout＜＜is_pointer＜int(*)(int)＞::value; //这将输出 1
也就是说int(*)(int)可以与T*形式匹配，匹配时T为int(int)。
最后一些细节
1. 我没有给出function_base的源代码，实际上那很简单，它最主要的成员就是union any_pointer型的数据成员
detail::function::any_pointer functor; //用于统一保存函数指针及仿函数对象指针
2. 我没有给出functor_manager的信息，实际上它与function的实现没有太大关系，它负责copy和delete函数对象，假如必要的话。所以我将它略去，它的源码在：”boost/function/function_base.hpp”里。
3. 我给出的源代码是将宏展开后的版本，实际的代码中充斥着让人眼花缭乱的宏，关于那些宏则又是一个奇妙的世界。Boost库通过那些宏省去了许多可见代码量。随着函数参数的不同，那些宏会扩展出function2,function3...各个版本。
本文只研究了int(int)型的情况，其它只是参数数目的改变而已。经过宏的扩展，function的偏特化版本将有:
template＜typename R,typename Allocator＞
class function＜R(),Allocator＞:public function0＜R,Allocator＞
{...};
template＜typename R,typename T0,typename Allocator＞
class function＜R(T0),Allocator＞:public function1＜R,T0,Allocator＞
{...};
template＜typename R,typename T0,typename T1,typename Allocator＞
class function＜R(T0,T1),Allocator＞:public function2＜R,T0,T1,Allocator＞
{...};
等更多版本，一共有BOOST_FUNCTION_MAX_ARGS+1个版本，BOOST_FUNCTION_MAX_ARGS为一个宏，表示最多能够接受有多少个参数的函数及仿函数对象，你可以重新定义这个宏为一个新值，以控制function所能支持的函数参数个数的最大值。其中的function0,function1,function2等名字也由宏扩展出。
更多内容请看C/C++技术专题专题，或
中查找“Boost源码剖析：C++泛型函数指针类”更多相关内容
中查找“Boost源码剖析：C++泛型函数指针类”更多相关内容更多精彩
赞助商链接
