Visual Studio 2022的MFC框架——theApp全局对象

 

我是荔园微风，作为一名在IT界整整25年的老兵，今天我们来重新审视一下Visual Studio 2022下开发工具的MFC框架知识。 

MFC中的WinMain函数是如何与MFC程序中的各个类组织在一起的呢？MFC程序中的类是如何与WinMain函数关联起来的呢？

面对这个问题，我们来分析一下。

双击我在我的《Visual Studio 2022的MFC框架——应用程序向导》一文中的项目例子中的类视图窗口中的CMfcApp类，跳转到该类的定义文件（Mfc.h）中。可以发现CMfcApp派生于 CWinApp类，后者表示应用程序类。

我们在类视图窗口中双击该类的构造函数，就跳转到该类的源文件（Mfc.cpp）中。在CMfcApp构造函数处设置一个断点，然后调试运行Mfc程序，将发现程序首先停在CMfcApp类的构造函数处，继续运行该程序。

这时程序才进入WinMain函数，即停在先前我在我的《Visual Studio 2022的MFC框架——WinMain函数》一文中的WinMain函数中设置的断点处。

按我们过去在C/C++编程的理解中，WinMain函数是程序的入口函数。也就是说，程序运行时首先应该调用的是WinMain函数，那么为什么这里程序会首先调用CMfcApp类的构造函数呢？

看一下CMfcApp的源文件，可以发现在程序中定义了一个CMfcApp类型的全局对象：theApp。代码如下。

//唯一的 CMfcApp对象

CMfcApp theApp;

MFC程序的全局变量都放置在类视图窗口中的“全局函数和变量”分支下，单击该分支即可看到程序当前所有的全局函数和变量。双击某个全局变量，即可定位到该变量的定义处。

在这个全局对象定义处设置一个断点，然后调试运行Mfc程序，将发现程序执行的顺序依次是：

1.theApp全局对象定义处

2.MfcApp构造函数

3.WinMain函数。

为了更好地解释这一过程，我们在项目解决方案下，添加一个新的“Windows控制台应用程序”项目，该项目的名称为：findwm。

接下来，在findwm.cpp文件中输入如下所示的代码。

#include "pch.h"
#include <iostream>

using namespace std； 

int s=100；

int main()

{

cout<<s<<endl；

return 0；

}

上述代码首先定义了一个int类型的全局变量s， 并给它赋了一个初值100。然后在main函数中将全局变量s的值输出到标准输出cout上。

将该项目设置为启动项目， 然后在main函数处设置一个断点， 调试运行该程序， 将会发现程序在进入main函数时， s的值已经是100了。在程序入口main函数加载时，系统就已经为全局变量或全局对象分配了存储空间，并为它们赋了初始值。

接下来，把全局变量s换成一个全局对象，看看结果如何。修改代码， 新定义一个CPoint类， 并定义该类的一个全局变量pt。

#include"pch.h"
#include<iostream>

using namespace std；

class CPoint
{
public:
　　CPoint()
   {

   }
};

CPoint pt;
void main()
{

} 

设置三个断点：CPoint构造函数处、pt全局对象定义处和 main函数定义处。选择调试运行 main函数，将会看到程序代码执行的先后顺序。

这时我们将发现findwm程序首先到达pt全局对象定义处；继续运行程序，程序到达CPoint类的构造函数；再继续运行程序，程序到达main函数处。

由此可见，无论是全局变量，还是全局对象，程序在运行时，在加载main函数之前，就已经为全局变量或全局对象分配了内存空间。

对一个全局对象来说，此时就会调用该对象的构造函数构造该对象，并进行初始化操作。

这解释了先前创建的Mfc程序的运行顺序为什么全局变量theApp的构造函数会在 WinMain 函数之前执行。

那么，为什么要定义一个全局对象theApp，让它在WinMain函数之前执行呢？该对象的作用是什么呢？我们回到Mfc项目，并将该项目设置为启动项目。

Win32 SDK应用程序的实例是由实例句柄(WinMain函数的参数hInstance)来标识的。而对MFC程序来说，通过产生一个应用程序类的对象来唯一标识应用程序的实例。每一个MFC程序有且仅有一个从应用程序类(CWinApp)派生的类。每一个MFC程序实例有且仅有一个该派生类的实例化对象，也就是theApp全局对象。该对象就表示了应用程序本身。

还记得子类构造函数的执行过程？当一个子类在构造之前会先调用其父类的构造函数。因此theApp对象的构造函数CMfcApp 在调用之前，会调用其父类CWinApp的构造函数，从而就把我们程序自己创建的类与Microsoft 提供的基类关联起来了。CWinApp的构造函数完成程序运行时的一些初始化工作。

下面让我们看看CWinApp类构造函数的定义。像前面搜索“WinMain”函数那样，找到Microsoft提供的CWinApp类定义的源文件：appcore.cpp，并在编辑环境中打开，其中CWinApp构造函数的代码如下。

CWinApp::CWinApp(LPCTSTR lpszAppName)
{
　　if (lpszAppName != NULL)
　   　m_pszAppName=_tcsdup(lpszAppName);
　　else
　   　m_pszAppName =NULL;
　　
    // initialize CWinThread state
　　AFX_MODULE_STATE* pModulestate =_AFX_CMDTARGET_GETSTATE();
　　ENSURE (pModulestate);
   AFX_MODULE_THREAD_STATE* pThreadstate =pModulestate->m_thread;
　　ENSURE(pThreadState);
　　ASSERT(AfxGetThread()== NULL);
　　pThreadstate->m_pCurrentwinThread=this;
　　ASSERT (AfxGetThread() == this);
　　m_hThread = ::GetCurrentThread();
　　m_nThreadID=::GetCurrentThreadId();

　　// initialize CWinApp state
　　ASSERT(afxCurrentWinApp == NULL);
   pModuleState->m_pCurrentWinApp this;
　　ASSERT (AfxGetApp ()== this);

　　// in non-running state until WinMain
　　m_hInstance= NULL;
　　m_hLangResourceDLL= NULL;
　　m_pszHelpFilePath= NULL;
　　m_pszProfileName= NULL;
　　m_pszRegistryKey= NULL;
　　m_pszExeName= NULL;
　　m_pszAppID= NULL;
　　m_pRecentFileList= NULL;
　　m_pDocManager= NULL;
　　m_atomApp= m_atomSystemTopic= NULL;
　　m_lpCmdLine= NULL;
　　m_pCmdInfo= NULL;
　　m_pDataRecoveryHandler= NULL;

　　// initialize wait cursor state
　　m_nWaitCursorCount =0;
　　m_hcurWaitCursorRestore= NULL;

　　// initialize current printer state
　　m_hDevMode= NULL;
　　m_hDevNames= NULL;
　　m_nNumPreviewPages =0;

　　// initialize DAO state
　　m_lpfnDaoTerm= NULL;

　　// other initialization
　　m_bHelpMode= FALSE;
　　m_eHelpType= afxwinHelp;
　　m_nSafetyPoolsize= 512;
　　m_dwRestartManagerSupportFlags =0;
　　m_nAutosaveInterval = 5 * 60 * 1000;
   m_bTaskbarInteractionEnabled= TRUE;

　　// Detect the kind of OS:
　　OSVERSIONINFO osvi;
　　osvi.dwosversionInfoSize= sizeof (OSVERSIONINFO);

　　#pragma warning( disable 4996)
　　  ::GetVersionEx(&osvi);
　　#pragma warning( default 4996)

　　m_bIsWindows7 =(osvi. dwMajorVersion ==6) && (osvi. dwMinorVersion >=1)|| (osvi. dwMajorVersion >6);

　　// Taskbar initialization:
　　m_bComInitialized= FALSE;

　　m_pTaskbarList= NULL;
　　m_pTaskbarList3= NULL;
　　m_bTaskBarInterfacesAvailable= TRUE;
}

上述CWinApp的构造函数中有这样两行代码：

pThreadState->m_pCurrentWinThread= this;

pModuleState->m_pCurrentWinApp= this;

m_pCurrentWinThread 对象的类型是 CWinThread,该类是 CWinApp 的父类。

根据C++继承性原理，这个this对象代表的是子类 CMfcApp的对象，即theApp。同时，可以发现CWinApp的构造函数有一个LPCTSTR类型的形参：lpszAppName。但是我们程序中CMfcApp的构造函数是没有参数的。如果基类的构造函数带有一个形参，那么子类构造函数需要显式地调用基类带参数的构造函数。那么,为什么我们程序中的 CMfcapp构造函数没有这么做呢?

如果某个函数的参数有默认值，那么在调用该函数时可以传递该参数的值，也可以不传递直接使用默认值即可。

class CWinApp : public CWinThread
{
　　DECLARE DYNAMIC (CWinApp)

public:

　　//Constructor

　　explicit CWinApp(LPCTSTR lpszAppName=NULL);

　　.....

可以看到，CWinApp构造函数的形参确实有一个默认值(NULL)。这样，在调用CWinApp类的构造函数时，就不用显式地去传递这个参数的值。

作者简介：荔园微风，1981年生，高级工程师，浙大工学硕士，软件工程项目主管，做过程序员、软件设计师、系统架构师，早期的Windows程序员，Visual Studio忠实用户，C/C++使用者，是一位在计算机界学习、拼搏、奋斗了25年的老将，经历了UNIX时代、桌面WIN32时代、Web应用时代、云计算时代、手机安卓时代、大数据时代、ICT时代、AI深度学习时代、智能机器时代，我不知道未来还会有什么时代，只记得这一路走来，充满着艰辛与收获，愿同大家一起走下去，充满希望的走下去。