Posted on 2007-11-08 11:05
天之骄子 阅读(1761)
评论(1) 编辑 收藏 引用
C++设计者在C++使用的早期并没有意识到RTTI(运行时类型检查)的重要性,后来随作框架结构的类库出现及其应用越来越广泛,RTTI就变得越来越重要了。例如下面的这个语句:
CWnd *pWnd;
任何人都知道对象pWnd是CWnd类型的指针。但是如果有一个类CView是从CWnd派生来的,对于下面的语句:
CWnd* CreateView()
{
return new CView;
}
对 于使用CreateView()的用户而然,pWnd = CreateView(),他如何确定pWnd所指向的对象的真正类型呢?因此,必须有一个能够在运行时刻就能够确定指针对象类型的方法,比如给每一个类 型的对象均添加一个IsKindOf()之类的方法,通过此方法判断指针对象的类型。
后来,RTTI被加入了C++的规范,成为C++一个内置的特性。
在MFC的设计者们设计MFC的时候,C++规范中并没有包含RTTI,但是他们很早就意识到这个问题,所以他们以一种独特的方式在MFC中实现 RTTI,采用这种方式实现的RTTI对于某个对象而言并不是必须的,也就是说,MFC的设计者们并不将RTTI强加于用户所设计的类型上,而是让用户根 据自己的需要选择是否他所设计的类型需要RTTI。因而这种方式比C++规范中内置的RTTI更灵活。
MFC的设计者们在MFC中采用下面的的方法来实现RTTI:
设计一个基类CObject,在CObject中增加RTTI功能,任何一个类型,如果需要具有RTTI功能,就必须直接或间接派生于CObject采 用宏实现RTTI,对于某个直接或间接从CObject派生来的类型而言,该宏可有可无,如果有该宏,它就具有RTTI功能,反之则无。
考察CObject
我们先从CObject开始,下面是它的定义:
class AFX_NOVTABLE CObject
{
public:
// Object model (types, destruction, allocation)
virtual CRuntimeClass* GetRuntimeClass() const;
virtual ~CObject(); // virtual destructors are necessary
// Diagnostic allocations
void* PASCAL operator new(size_t nSize);
void* PASCAL operator new(size_t, void* p);
void PASCAL operator delete(void* p);
void PASCAL operator delete(void* p, void* pPlace);
void PASCAL operator delete(void *p, LPCSTR lpszFileName, int nLine);
// Disable the copy constructor and assignment by default so you will get
// compiler errors instead of unexpected behaviour if you pass objects
// by value or assign objects.
protected:
CObject();
private:
CObject(const CObject& objectSrc); // no implementation
void operator=(const CObject& objectSrc); // no implementation
// Attributes
public:
BOOL IsSerializable() const;
BOOL IsKindOf(const CRuntimeClass* pClass) const;
// Overridables
virtual void Serialize(CArchive& ar);
// Implementation
public:
static const AFX_DATA CRuntimeClass classCObject;
};
总的来说,CObject定义了整个从其派生的家族的所有成员所具有的两个基本的能力:
运行时的动态类型检查(RTTI)能力和序列化能力。在早期的C++版本中,没有规定RTTI,但MFC的作者们早就未扑先知,以这种构架的形式定义并实现RTTI。体现RTTI的是CObject中的两个成员函数:
virtual CRuntimeClass * GetRuntimeClass() const;
BOOL IsKindOf(const CRuntimeClass *pClass) const;
其中,前一个函数用来访问存储RTTI信息的一个CRuntimeClass类型的结构,后一个函数供在运行时刻进行类型判断。我们先来看看CRuntimeClass结构的定义,看看它究竟保存了哪些类型信息。
struct CRuntimeClass
{
// Attributes
LPCSTR m_lpszClassName;
int m_nObjectSize;
UINT m_wSchema; // schema number of the loaded class
CObject* (PASCAL* m_pfnCreateObject)(); // NULL => abstract class
CRuntimeClass* m_pBaseClass;
// Operations
CObject* CreateObject();
BOOL IsDerivedFrom(const CRuntimeClass* pBaseClass) const;
// Implementation
void Store(CArchive& ar) const;
static CRuntimeClass* PASCAL Load(CArchive& ar, UINT* pwSchemaNum);
// CRuntimeClass objects linked together in simple list
CRuntimeClass* m_pNextClass; // linked list of registered classes
};
上 面就是CRuntimeClass的定义,m_lpszClassName保存类的名称,m_nObjectSize保存类的实例数据所占内存的的大小。 我们重点要关注的是m_pBaseClass成员,它是指向名称为m_lpszClassName的类的基类的CRuntimeClass的指针,因此, CRuntimeClass就形成了一个继承链表,这个链表记录了某一族类的继承关系。
RTTI的实现:
实现RTTI的除了上面两个函数外,还有几个相关的宏。我们先看看GetRuntimeClass()和IsKindOf()的实现.
1.GetRuntimeClass()的实现
CRuntimeClass* CObject::GetRuntimeClass() const
{
return RUNTIME_CLASS(CObject);
}
关键就在RUNTIME_CLASS这个宏上,RUNTIME_CLASS宏的实现如下:
#define RUNTIME_CLASS(class_name) ((CRuntimeClass*)(&class_name::class##class_name))将宏展开,上面的实现就变成:
CRuntimeClass* CObject::GetRuntimeClass() const
{
return (CRuntimeClass*)(&CObject::classCObject);
}
也就是说,它返回CObject类的一个static型的成员classCObject。
2.IsKindOf()的实现
BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const
{
ASSERT(this != NULL);
// it better be in valid memory, at least for CObject size
ASSERT(AfxIsValidAddress(this, sizeof(CObject)));
// simple SI case
CRuntimeClass* pClassThis = GetRuntimeClass();
return pClassThis->IsDerivedFrom(pClass);
}
前两行我们不管它,关键在于最后一行pClassThis->IsDerivedFrom(pClass),归根结底就是调用 CRuntimeClass的IsDerivedFrom()方法。下面是CRuntimeClass的成员IsDerivedFrom()的实现:
BOOL CRuntimeClass::IsDerivedFrom(const CRuntimeClass* pBaseClass) const
{
ASSERT(this != NULL);
ASSERT(AfxIsValidAddress(this, sizeof(CRuntimeClass), FALSE));
ASSERT(pBaseClass != NULL);
ASSERT(AfxIsValidAddress(pBaseClass, sizeof(CRuntimeClass), FALSE));
// simple SI case
const CRuntimeClass* pClassThis = this;
while (pClassThis != NULL)
{
if (pClassThis == pBaseClass) return TRUE;
pClassThis = pClassThis->m_pBaseClass;
}
return FALSE; // walked to the top, no match
}
关键是上面的一段循环代码:
while (pClassThis != NULL)
{
if (pClassThis == pBaseClass) return TRUE;
pClassThis = pClassThis->m_pBaseClass;
}
它从继承链表的某一节点this开始,向后搜索比较,确定继承关系。
到这里,或许有人要问,这些CRuntimeClass结构是如何产生的呢?这是一个很好的问题,解决了这个问题,就完全清楚了MFC中RTTI的实现。 使用过Visual C++开发程序的人都应该记得DECLARE_DYNAMIC和IMPLEMENT_DYNAMIC这两个宏,它们分别用来定义相应类的static CRuntimeClass成员和对该成员初始化。
DECLARE_DYNAMIC宏的定义:
#define DECLARE_DYNAMIC(class_name) \
public: \
static const AFX_DATA CRuntimeClass class##class_name; \
virtual CRuntimeClass* GetRuntimeClass() const; \
例如DECLARE_DYNAMIC(CView)展开成为:
public:
static const AFX_DATA CRuntimeClass classCView;
virtual CRuntimeClass* GetRuntimeClass() const;
由此可见,DECLARE_DYNAMIC宏用来在类的定义中定义静态CRuntimeClass变量和虚拟GetRuntimeClass()函数。可以 推断,IMPLEMENT_DYNAMIC宏一定是用来初始化该静态变量和实现GetRuntimeClass()函数,。不错,正是这样!
IMPLEMENT_DYNAMIC宏的定义:
#define IMPLEMENT_DYNAMIC(class_name, base_class_name) \
IMPLEMENT_RUNTIMECLASS(class_name, base_class_name, 0xFFFF, NULL)
#define IMPLEMENT_RUNTIMECLASS(class_name, base_class_name, wSchema, pfnNew) \
AFX_COMDAT const AFX_DATADEF CRuntimeClass class_name::class##class_name = { \
#class_name, sizeof(class class_name), wSchema, pfnNew, \
RUNTIME_CLASS(base_class_name), NULL }; \
CRuntimeClass* class_name::GetRuntimeClass() const \
{ return RUNTIME_CLASS(class_name); } \
例如IMPLEMENT_DYNAMIC(CView, CWnd)展开如下:
file://下面展开的代码用来初始化静态CRuntimeClass变量
AFX_COMDATA const AFX_DATADEF CRuntimeClass CView::classCView =
{
“CView”, file://m_lpszClassName
sizeof(class CView), file://m_nObjectSize
0xffff, file://m_wSchema
NULL, file://m_pfnCreateObject
(CRuntimeClass*)(&CWnd::classCWnd), file://m_pBaseClass
NULL file://m_pNextClass
}
file://下面的代码用来实现GetRuntimeClass()函数
CRuntimeClass* CView::GetRuntimeClass() const
{
return (CRuntimeClass*)(&CView::classCView);
}
总的来说,同RTTI有关的宏有下面几对:
DECLARE_DYNAMIC和IMPLEMENT_DYNAMIC
这一对宏能够提供运行是类型判断能力。(定义并实现IsKindOf())
DECLARE_DYNCREATE和IMPLEMENT_DYNCREATE
这一对宏除了能够提供类型判断能力外,还能够提供动态创建对象的能力.(定义并实现IsKindOf()和CreateObject())
DECLARE_SERIAL和IMPLEMENT_SERIAL
这一对宏除了提供类型判断能力、动态创建对象能力外,还具有序列化功能。(定义并实现IsKindOf()、CreateObject()和Serialize())
框窗、视图和文档对象的创建顺序和过程
前面说过,框窗、视图和文档是一个三位一体的框架结构,但实际上,这个三位一体并不是紧耦合的,这个“不是紧耦合“的意思就是,可以将三者分开,可以去掉文档,而只保留视图和框窗并且维持两者的原有关系;也可以去掉视图和文档,而只留框窗,程序照样可以在框架内运作。
在MFC中,将三者组织在一起的是文档模板(Document Template),就我个人观点而然,在一般的应用中,加入文档模板是没有必要的。
MFC编程特点
如 果你曾经使用过传统的windows编程方法开发应用程序,你会深刻地体会到,即使是开发一个简单的windows应用程序也需要对windows的编程 原理有很深刻的认识,同时也要手工编写很多的代码。因为程序的出错率几乎是随着代码长度的增加呈几何级数增长的,这就使得调试程序变得非常困难。所以传统 的windows编程是需要极大的耐心和丰富的编程经验的。
近几年来,面向对象技术无论是在理论还是实践上都在飞速地发展。面向对象 技术中最重要的就是“对象”的概念,它把现实世界中的气球、自行车等客观实体抽象成程序中的“对象”。这种“对象”具有一定的属性和方法,这里的属性指对 象本身的各种特性参数。如气球的体积,自行车的长度等,而方法是指对象本身所能执行的功能,如气球能飞,自行车能滚动等。一个具体的对象可以有许多的属性 和方法,面向对象技术的重要特点就是对象的封装性,对于外界而言,并不需要知道对象有哪些属性,也不需要知道对象本身的方法是如何实现的,而只需要调用对 象所提供的方法来完成特定的功能。从这里我们可以看出,当把面向对象技术应用到程序设计中时,程序员只是在编写对象方法时才需要关心对象本身的细节问题, 大部分的时间是放在对对象的方法的调用上,组织这些对象进行协同工作。
MFC的英文全称是Microsoft Fundation Classes,即微软的基本类库,MFC的本质就是一个包含了许多微软公司已经定义好的对象的类库,我们知道,虽然我们要编写的程序在功能上是千差万别 的,但从本质上来讲,都可以化归为用户界面的设计,对文件的操作,多媒体的使用,数据库的访问等等一些最主要的方面。这一点正是微软提供MFC类库最重要 的原因,在这个类库中包含了一百多个程序开发过程中最常用到的对象。在进行程序设计的时候,如果类库中的某个对象能完成所需要的功能,这时我们只要简单地 调用已有对象的方法就可以了。我们还可以利用面向对象技术中很重要的“继承”方法从类库中的已有对象派生出我们自己的对象,这时派生出来的对象除了具有类 库中的对象的特性和功能之外,还可以由我们自己根据需要加上所需的特性和方法,产生一个更专门的,功能更为强大的对象。当然,你也可以在程序中创建全新的 对象,并根据需要不断完善对象的功能。
正是由于MFC编程方法充分利用了面向对象技术的优点,它使得我们编程时极少需要关心对象方法的实现细节,同时类库中的各种对象的强大功能足以完成我们程序中的绝大部分所需功能,这使得应用程序中程序员所需要编写的代码大为减少,有力地保证了程序的良好的可调试性。
最后要指出的是MFC类库在提供的对象的各种属性和方法都是经过谨慎的编写和严格的测试,可靠性很高,这就保证了使用MFC类库不会影响程序的可靠性和正确性。