关于type_info总结

最新推荐文章于 2024-10-26 16:38:27 发布

weixin_33962621

最新推荐文章于 2024-10-26 16:38:27 发布

阅读量452

点赞数

CC 4.0 BY-SA版权

文章标签： c/c++

原文链接：http://www.cnblogs.com/zjushuiping/archive/2012/09/06/2673280.html

本文介绍了如何使用C++中的type_info类实现类似反射的功能，包括如何获取类名、使用hash_code优化字符串比较、避免冗余实现及提高代码效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

c++没有反射机制，我们可以经由过程c++的说话特点去实现同样的功能。本文介绍应用type_info实现的一些发射特点。

1 type_info简介:

class type_info {
public:
    _CRTIMP virtual ~type_info（）;
    _CRTIMP int operator==（const type_info& rhs） const;
    _CRTIMP int operator!=（const type_info& rhs） const;
    _CRTIMP int before（const type_info& rhs） const;
    _CRTIMP const char* name（） const;
    _CRTIMP const char* raw_name（） const;
private:
void *_m_data;
char _m_d_name[1];
    type_info（const type_info& rhs）;
    type_info& operator=（const type_info& rhs）;
};

（注: c++0 x01增长了hash_code办法，获取类名对应的hash值）

应用type_info须要重视3点:

（1）type_info的机关函数和赋值操纵符都为私有。是以不要试图去定义或复制一个type_info对象。创建type_info对象的独一办法是应用typeid操纵符。若是想应用type_info的引用，可以应用const type_info& info = typeid（foo）。

（2） type_info::name返回的是类似于"class CBase*"之类的名字，并且c++标准只是告诉编译器须要实现type_info::name函数，不合编译器编译运行后输出不一样。

（3）对于父类指针类型变量，typeid（ptr）.name不具有多态性，仍返回此父类的指针类名，如"class CBase*"。若是直接传入对象如typeid（*ptr）.name则具有多态性，将返回"class CDevievd"类似的子类类名。

2 巧用type_info

（1）获得类名的一种办法是在类中实现class_name（）办法，如

class CDataType 
{
public:
virtual char* class_name（） { return "CDataType"; }
};

这种办法的一个毛病就是强迫每一个类必须实现这个函数，不然后续的工作就无法完成。

下面是一个为数据注册创建者，并按照数据类型获取创建者的例子，看一下它是如何工作的。

// 数据
class CDataType 
{
public:
virtual char* class_name（） { return "CDataType"; }
};
class CDataTypeA : public CDataType 
{
public:
virtual char* class_name（） { return "CDataTypeA"; }
};
class CDataTypeB : public CDataType
{
public:
virtual char* class_name（） { return "CDataTypeB"; }
}

// 数据创建者
class CreatorType {};
class CreatorForDataA : public CreatorType {};
class CreatorForDataB : public CreatorType {};

typedef std::string KeyType;
static std::map<std::string， CreatorType*> nameMap;

void RegistCreator（KeyType key， CreatorType* creator）
{
    nameMap[key] = creator;
}

CreatorType* GetCreator（ CDataType* data ）
{
return nameMap[data->class_name（）];
}

void main（）
{
    RegistCreator（ "CDataTypeA"， new CreatorForDataA ）;
    RegistCreator（ "CDataTypeB"， new CreatorForDataB ）;

    CDataTypeA* dataA = new CDataTypeA;

    CreatorType* creator = GetCreator（dataA）;
}

为每个数据强迫加一个class_name虚函数看起来是否有点冗余？

下面我们用type_info来实现雷同的功能。

// 数据
class CDataType {};
class CDataTypeA : public CDataType {};
class CDataTypeB : public CDataType {};

CreatorType* GetCreator（ CDataType* data ）
{
return nameMap[typeid（*data）.name（）];
}

void main（）
{
    RegistCreator（ "CDataTypeA"， new CreatorForDataA ）;
    RegistCreator（ "CDataTypeB"， new CreatorForDataB ）;

    CDataTypeA* dataA = new CDataTypeA;

    CreatorType* creator = GetCreator（dataA）;
}

斗劲一下，这个版本的代码要简单很多了，也有较好的扩大性，或许我们可以放松一下了。

可是没过几许天题目就来了，有的同事愁闷多量的字符串斗劲会影响速度，固然map是很高效的。愁闷确切是不须要的，杀手锏还在你的手中——hash_code。

hash_code是把字符串映射到一个独一整数，应用整数作为map键值效力要比string高很多。空话不说，上代码。

typedef int KeyType;
static std::map<KeyType， CreatorType*> nameMap;

void RegistCreator（KeyType key， CreatorType* creator）
{
    nameMap[key] = creator;
}

CreatorType* GetCreator（ CDataType* data ）
{
return nameMap[typeid（*data）.hash_code（）];
}

void main（）
{
    RegistCreator（ typeid（CDataTypeA）.hash_code（）， new CreatorForDataA ）;
    RegistCreator（ typeid（CDataTypeB）.hash_code（）， new CreatorForDataB ）;

    CDataTypeA* dataA = new CDataTypeA;

    CreatorType* creator = GetCreator（dataA）;
}

若是你的c++版本不敷，发明type_info底子没有hash_code办法，没有关系，可以应用下面的办法庖代。

size_t hash_code（ const type_info& info ）
    {
// hash name（） to size_t value by pseudorandomizing transform
        const char *_Keyval = info.name（）;
        size_t _Val = 2166136261U;
        size_t _First = 0;
        size_t _Last = _CSTD strlen（_Keyval）;
        size_t _Stride = 1 + _Last / 10;

for（; _First < _Last; _First += _Stride）
            _Val = 16777619U * _Val ^ （size_t）_Keyval[_First];
return （_Val）;
    }

转载于:https://www.cnblogs.com/zjushuiping/archive/2012/09/06/2673280.html