分享
 
 
 

Boost源码剖析之:泛型函数指针类boost::function(修订版)

王朝other·作者佚名  2006-01-09
窄屏简体版  字體: |||超大  

Boost源码剖析之:泛型函数指针类boost::function(修订版)

刘未鹏 /文

2003年9月发表于《程序员》,本文较之有极大改动,特别在中后部分:-)

前奏

如你所知,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非常巧妙地实现了这点,并且阻止了被形式不兼容的函数赋值的操作。

探险

好吧,准备好,我们要出发了,进行深入源码世界的探险。

先看一个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可以被赋给任何指针,所以它被选出,执行缺省的构造行为。

基类 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中也对该函数模板做了扩充,使它可以接受任意多个参数的成员函数。

做一个,送一个——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++的一切,另外还喜欢的是.NET,虽然C#很烂,但是.NET的确不错,正打算写一个剖析Rotor(Shared source CLI)源代码的系列,深掘.NET内部的架构及实现,但由于正忙于考研,不知何年何月才能开始...

于 2004-10-2 23:24 修改完毕 :-)

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有