我是荔园微风,作为一名在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深度学习时代、智能机器时代,我不知道未来还会有什么时代,只记得这一路走来,充满着艰辛与收获,愿同大家一起走下去,充满希望的走下去。