进入MFC讲坛的前言(五)

框窗、视图和文档及其关系 

  MFC架构的另外一个特色是它的框窗、视图和文档这个三位一体的结构,它是一个典型的MVC(Model、View and Controler)结构。严格的讲,框窗不属于MVC中的任何一项,MFC设计者将框窗加进来是为了能更好的协调文档 和视图。而MVC中的Controler这一项,则是应用本身的应用逻辑。 在这三者中,需要特别注意的、也最能够体现个人的编程水平的是框窗。一旦三者都存在于内存中,它们的关系就变得很简单。本章将讨论下述内容:

  1.MFC的RTTI(Run Time Type Inspection,运行时类型检查)

   框窗、视图和文档的创建顺序和过程。

   框窗、视图和文档的删除顺序和过程。

   框窗、视图和文档之间的相互访问接口。

   框窗、视图和文档对菜单和工具条消息处理的先后顺序

  MFC的RTTI

  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),就我个人观点而然,在一般的应用中,加入文档模板是没有必要的。

时间: 2024-09-29 04:37:25

进入MFC讲坛的前言(五)的相关文章

进入MFC讲坛的前言(一)

在这里,我想谈谈自己学习MFC的一些体会.我是从1997年才开始在Window下编写程序的.在这之前,我编写过一些DOS程序,包括一个简单的全屏幕编辑器和一个带函数的表达式解释器,都是一些小的程序.Window 3.1流行后,我开始在它下面编写程序. 从编写DOS程序到编写Window程序,需要从编程思想上作一个比较大的调整.在DOS下编写程序,程序的总体流程完全由应用程序自己控制:但在Window下,程序的总体流程是由操作系统控制的,这一点对在DOS下"胡作非为"的DOS程序员而然,

进入MFC讲坛的前言(三)

MFC中的窗口创建及窗口消息映射 我经常碰到有人问我有关窗口创建的问题,他们经常把用HWND描述的系统窗口对象和用CWnd描述的MFC的窗口对象混淆不清.这两者之间是紧密联系在一起的,但是MFC为了自身的管理,在CWnd中加了一些额外的内容,包括如何从HWND生成CWnd. 在MFC中,有几种典型的窗口对象,CWnd描述的一般窗口对象,CView描述的视图对象,CFrameWnd描述的SDI框窗对象,CMDIFrameWnd描述的MDI框窗对象等等.在这一章中,主要讨论下述内容: MFC中窗口的

进入MFC讲坛的前言(二)

MFC的WinMain  使用MFC编程的程序员刚开始都会提出这样一个问题:我的程序是从哪儿开始执行的?回答是:从WinMain()开始执行的.提出这样的问题是由于在他们所编写的MFC应用中看不到WinMain()函数.这个函数是隐藏在MFC框架中,MFC的设计者将它作得很通用(这主要得益于Window的消息驱动的编程机制,使得作一个通用的WinMain()很容易),因此在一般情况下,无需更改WinMain()的代码,MFC的设计者也不提倡程序员修改WinMain()的代码.在MFC中,实际实现

进入MFC讲坛的前言(四)

MFC的消息映射机制  MFC的设计者们在设计MFC时,紧紧把握一个目标,那就是尽可能使得MFC的代码要小,速度尽可能快.为了这个目标,他们使用了许多技巧,其中很多技巧体现在宏的运用上,实现MFC的消息映射的机制就是其中之一. 同MFC消息映射机制有关的宏有下面几个: DECLARE_MESSAGE_MAP()宏 BEGIN_MESSAGE_MAP(theClass, baseClass)和END_MESSAGE_MAP()宏 弄懂MFC消息映射机制的最好办法是将找出一个具体的实例,将这些宏展开

剖析MFC六大关键技术(五六)--消息映射与命令传递

说到消息,在MFC中,"最熟悉的神秘"可算是消息映射,那是我们刚开始接触MFC时就要面对的东西.有过SDK编程经验的朋友转到MFC编程的时候,一下子觉得什么都变了样.特别是窗口消息及对消息的处理跟以前相比,更是风马牛不相及的.如文档不是窗口,是怎样响应命令消息的呢? 初次用MFC编程,我们只会用MFC ClassWizard为我们做大量的东西,最主要的是添加消息响应.记忆中,如果是自已添加消息响应,我们应何等的小心翼翼,对BEGIN_MESSAGE_MAP()--END_MESSAGE

VC MFC专题

MFC程序如何实现给对话框添加背景图片 MFC游戏开发笔记十 游戏中的碰撞检测进阶:地图类型&障碍物 MFC游戏开发笔记九 游戏中的碰撞判定初步&怪物运动简单AI MFC游戏开发笔记八 游戏特效的实现(二):粒子系统 MFC游戏开发笔记七 游戏特效的实现(一):背景滚动 MFC游戏开发笔记六 图像双缓冲技术:实现一个流畅的动画 MFC游戏开发笔记五 定时器和简单动画 MFC游戏开发笔记四 键盘响应和鼠标响应:让人物动起来 MFC游戏开发笔记三 游戏贴图与透明特效的实现 MFC游戏开发笔记二

MFC教程(11)-- MFC下的文件类

文件操作的方法 使用Visual C++编程,有如下方法进行文件操作: (1)使用标准C运行库函数,包括fopen.fclose.fseek等. (2)使用Win16下的文件和目录操作函数,如lopen.lclose.lseek等.不过,在Win32下,这些函数主要是为了和Win16向后兼容. (3)使用Win32下的文件和目录操作函数,如CreateFile,CopyFile,DeleteFile,FindNextFile,等等. Win32下,打开和创建文件都由CreateFile完成,成功

mfc-最近觉得自己写的MFC程序好丑,怎么美化界面呀

问题描述 最近觉得自己写的MFC程序好丑,怎么美化界面呀 如题,老师说我们写的 MFC程序太丑,想要我们做好看点,怎么弄哇 解决方案 可以使用一些第三方的库,google(每个分号为一个搜索目标) MFC换肤.MFC金山UI.BCGControlbar等. 解决方案二: 程序丑和界面丑是两个概念,界面丑的话,可以用第三方库,可以写一些美化窗口的类加载到你写的界面里面,相当与覆盖.还可以做个图片代替界面 解决方案三: 估计是版本比较老吧,比如我用的就是VC6.0+MFC4.2,界面确实比较老,适合

c++-怎样给C++程序加个界面

问题描述 怎样给C++程序加个界面 我在VS2013上写了2个C++项目(用来实现socket通信,一个项目是客户端,一个是服务器). 现在想给它加个界面,可是鄙人只会MFC和C#. 怎样可以比较省事加一个界面给它呢? 或者说怎样可以比较容易根据现在的C++代码来重写个C#项目 解决方案 最简单的就是用托管的C++,那样除了语法略微改变,和C#做的一样,也使用WinForms 解决方案二: 也就是VS中新建一个C++ -> Windows Forms项目 解决方案三: WIN32和MFC都可以,