c++对象模型 模板 异常处理 执行期类型识别

template

声明

​ 当我们声明一个template class、template class memberfunction等,会发生何事?

成都创新互联公司是专业的明山网站建设公司,明山接单;提供网站设计、成都网站设计,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行明山网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!

​ 现有如下片段:

template 
class Point
{
public:
    enum Status{ unallocated, normalized };
    
    Point( Type x = 0.0, Type y = 0.0, Type z = 0.0 );
    ~Point();
    
    void* operator new( size_t );
    void operator delete( void*, size_t );
    
    //...
    
private:
    static Point *freeList;
    static int chunkSize;
    Type _x, _y, _z;
}

​ 声明一个template class,在程序中编译器对其并没有任何反应。换句话说,上述的data member其实并不可用

实例化

  • 我们需要显示地指定类型才可使用data member:
Point::Status s;

Point::freeList;

//如下会产生第二个freeList实例
Point::freeList;

//定义指针指向特定实例,程序中啥也没发生。因为编译器不需要知道与该class有关的任何member数据,也没必要初始化template实例,且指针可以为0
Point< float >* ptr = 0;

//reference则不同,它需要实例化,因为reference是需要绑定对象的
const Point& ref = 0;

//扩展
Point temp( (float) 0 );
const Point& ref = temp;

//导致实例化
const Point origin;

​ 对于int和long相同的架构中,以下两个实例化c++standard并未对此进行强制规定应实例化一个还是两,不过大部分编译器都是实例化两个:

Point pi;
Point pi;
  • 目前的编译器,面对一个template的处理是完全解析但不做类型检验;只有在实例化操作发生时才做类型检验
  • template class内的member functions只有在被使用的时候,才会被实例化

名称决议

  • 在c++standard规定了template两个不一样的端,分别是定义template(template定义的文件)的程序端和实例化template(使用的特定例子)的程序端

    //定义template端
    //只有一个foo()声明位于定义端内
    extern double foo( double );
    
    template< class type >
    class A
    {
    public:
        void do1()
        {
            _member = foo( _val );
        }
        
        type do2()
        {
            return foo( _member );
        }
        //...
        
    private:
        int _val;
        type _member;
    }
    
    //实例化端
    //两个foo()声明在实例化端内
    extern int foo( int );
    
    template< class type >
    class A
    {
    public:
        void do1()
        {
            _member = foo( _val );
        }
        
        type do2()
        {
            return foo( _member );
        }
        //...
        
    private:
        int _val;
        type _member;
    }
    
    A a;
    
    //应该调用extern double foo( double )。因为_val的类型与template type参数类型无关
    a.do1();
    
    //应调用extern int foo( int )。因为_member与template type参数类型有关
    a.do2();
    
  • template中,对一个nonmenber name的决议结果是根据此name的使用是否与"用以实例化该template的参数类型"有关来决定:

    • 若其使用互不相关,则使用定义端来决定name
    • 若其使用有关联,则使用实例化端来决定name
  • 编译器必须保持两个端上下文(scope contexts):

    • 定义端。专注一般的template class
    • 实例化端。专注特定实例

异常处理

  • 想要支持异常处理,编译器的主要工作是找出catch子句以处理被抛出来的exception

  • 异常处理由三个主要组件构成:

    1. 一个throw子句。它再程序某处发出一个exception,被抛出的exception可为内建类型,亦可为自定类型
    2. 一个或多个catch子句。每个catch子句都为一个exception handler。表示此子句准备处理某种类型的exception,且在封闭的大括号区段中提供实际的处理程序
    3. 一个try区段。他被围绕一系列叙述句,这些叙述句可能会引发catch子句起作用
  • 当一个exception被抛出,控制权会从函数调用中被释放出,并寻找一个吻合的catch子句。若没有则调用默认处理例程terminate()。当控制权被释放,堆栈中每个函数调用也就被推离,被推离前函数的local class objects的destructor会被调用

    Point* mumble
    {
        //区域一
        Point* pt1, * pt2;
        //若一个exception于此被抛出,mumble()会被推出堆栈
        pt1 = foo();	
        if( !pt1 ) return 0;
        
        //区域二
        Point p;
        //若一个exception于此被抛出,在推出mumble()前需要先调用p的destructor
        pt2 = foo();
        if( !pt2 ) return pt1;
    }
    
    • 支持以上exception handling,编译器有两种策略:
      1. 把两个区域(上面两个exception)以个别的"将被摧毁的local objects"链表(在编译器准备妥当)联合起来
      2. 让两个区域共享同一个链表,该链表在执行期扩大或缩小
    • 一个函数可以分为多个区段:
      1. try以外的区域,且没有active local objects
      2. try以外的区域,但有一个以上的active local objects需要析构
      3. try以内的区域

​ 现有一函数含有对一块共享内存的locking和unlocking操作,此时异常处理不保证能正确运行:

void mumble( void* arena )
{
    Point* p = new Point;
    smLock( arena );
    
    //若此处有exception被抛出,会产生问题
    //...
    
    smUnLock( arena );
    delete p;
}

//因此我们需要安插default catch子句
void mumble( void* arena )
{
    Point* p = new Point;
    smLock( arena );
    
    try
    {
        smLock( arena );
    }
    catch(...)
    {
        smUnLock( arena );
        delete p;
        throw;
    }
    
    smUnLock( arena );
    delete p;
}
  • 处理资源管理,一个办法是将资源需求封装于class object内,并由destructor释放资源

​ 当一个exception发生时,编译系统必须完成以下:

  1. 检验发生throw操作的函数
  2. 决定throw操作是否发生在try区段
  3. 若是,编译系统必须把exception type拿来和每个catch子句比较
  4. 若比较后吻合,流程控制交给catch子句
  5. 若throw的发生不在try区段,或没有一个catch子句吻合,那么系统必须摧毁所有active local objects,从堆栈中将目前的函数推离,到下一个函数。再重复2-5
  • 编译器必须标示出之前所提到的多个区段,并使它们对执行期的异常处理有所作用。有一个策略是构造program counter-range表格:

    program counter内含下一个即将执行的程序指令。为了在一个内含try区段的函数中标示出某区域,可以把program counter的起始值和结束值存储在范围表格

    当throw发生时,目前的program counter值拿来与对应的范围表格进行对比,以决定目前作用中的区域是否在一个try区段内。若是,则需找出相关catch子句;若无法处理或exception再次被抛出,目前此函数会从堆栈中被推出,而program counter会被设定为调用端地址,循环将再度开始

  • 对于被抛出的exception,编译器必须产生一个类型描述器,对exception的类型进行编码,若为一个derived type,编码内容必须包含其所有base class类型信息(可能被member function捕捉)。编译器还必须为每一个catch子句产生一个类型描述器。执行期的handler会将"被抛出的object的类型描述器"和"每一个catch子句的类型描述器"进行比较,直到吻合或是堆栈已被推离

执行期类型识别

  • downcast有效地把一个base class转换为继承结构的derived class,但其有潜在的危险,因为它遏制了类型系统的作用

  • 一个type-safe downcast必须在执行期对指针查询,看其是否指向它所表达的object的真正类型。想要支持type-safe downcast,需要以下要求:

    1. 需要额外的空间存储类型信息,通常为指针
    2. 需要额外的时间来决定执行期的类型
  • c++的RTTI机制提供安全的downcast设备,但只对多态类型有效

  • dynamic_cast可以在执行期决定真正的类型

  • type-safe dynamic_cast:

    • 若downcast为安全的,则会传回被适当转换过的指针;若不安全,则传回0
    • 对一个class指针施行dynamic_cast,会获得true或flase
      1. 若传回真正的地址,则表示这一object的动态类型被确定,一些与类型有关的操作可以施行于此
      2. 若传回0,则表示没有指向任何object,应该以另一种逻辑施行于未确定的object
    • 对于reference dynamic_cast同样适用,但若为non-type-safe cast,结果和指针不同。因为reference不可以把自己设为0。因此会有另一套方案:
      1. 若reference真正参考到适当的derived class,downcast被执行
      2. 若reference并不真正是某种derived class,由于不能传回0,则抛出bad_cast exception
  • dynamic_cast的成本:编译器产出类型描述器

    //fct为type派生
    typedef type* ptype;
    typedef fct* pfct;
    
    do( ptype pt )
    {
        if( pfct pf = dynamic_cast(pt) )
        {
            //...
        }
        
        //转换
        //virtual table第一个slot内含type_info object地址
        ((type_info*)(pt->vptr[0]))->_type_descriptor
    
    }
    

分享文章:c++对象模型 模板 异常处理 执行期类型识别
分享地址:http://scyanting.com/article/dsoiego.html