胖头猫游戏提供热门游戏下载和手游攻略!

理解和比较C、C++控制台程序、Windows API程序和MFC程序

发布时间:2025-05-09浏览:54

函数由函数头和函数体组成。函数头包括域属性(例如外部域、静态域或类域)、返回值类型、函数名称和参数。域属性包括它们在多文件编程中的可见范围。他们是某个阶级的成员吗?返回值类型是指函数返回值的具体数据类型(可以理解为函数输出的一部分)。函数名是存储在内存代码区的函数首地址,用于函数调用和函数指针的右值。参数可以理解为函数的输入和输出(如果使用引用或指针作为参数,则可以理解为输出,因为它操作或更新的数据是地址值指向的内存单元引用或指针)。在C\C++中,函数体位于{}中,函数体就是函数函数的具体实现。

如果用手机来理解函数的概念的话,手机暴露的操作界面就像函数头,外壳里的组件就像函数体,外壳就像{}。

函数开发者和用户可以从不同的角度理解函数的结构。函数开发者需要对函数头作为接口的友好性和稳定性负责,以及函数体的友好性和稳定性,以确保函数功能的实现。空间和时间效率。函数的使用者不需要关心函数的具体实现(当然了解其具体实现可以更好地加深对函数的理解),即不关心函数体的具体内容,而是只关心函数的具体使用细节。即函数体的内容。

就像手机一样,手机开发者负责从外部操作到内部组件的一切,而手机购买者(用户)只需要关心如何使用。

一个数据集D和操作这个数据集D的代码集C如何能够更好的形成一个整体,体现在函数的概念上,即数据集D是通过参数和局部变量构成的,而在函数体中包含指向代表代码集C的函数的函数指针。但是,这种封装仍然没有完全体现。如果将数据集D以及操作这个数据集D的代码集C都归属(或限定)到某个类别,并设置访问控制(访问修饰符)的概念,就可以充分体现这种封装性。这个思想就是面向对象的类类型概念。访问控制就像手机壳。用public修饰的类(对象)的属性(数据集D)或方法(代码集C),就是类(对象)提供的接口(接口),是public的,公共的。曝光,用户密切关注;而通过private修饰的类(对象)的属性(数据集D)或方法(代码集C)是类(对象)提供的具体实现,是私有的、隐藏的。用户无需密切关注。

因此,一些编程高手针对一些经常使用的函数,开发出了接口友好稳定、实现效率高的函数和类,并存放在库中,即函数库或类库中,以供共享。一些优秀的函数库或类库已经成为编程语言的组成部分。

计算机语言的应用程序运行在某种操作系统上,某种操作系统对某种语言的支持是通过其某种语言的函数库或类库来实现的。

1 控件台程序

控制台程序只关心数据,不关心界面。它在一个简单的Shell 中执行。

控制台程序使用字符进行交互,不需要鼠标操作,即没有图形界面,也不需要使用控件作为输入输出媒体。

window api和MFC主要使用控件(窗口)作为交互媒介,因而有资源对象(不是类类型对象)的概念,以及事件消息和消息响应函数(Message Based,Event Driven)的概念。

2 Windows API编程

当Windows操作系统开始占据主导地位时,在Windows平台下开发应用程序成为一种需要。在Windows编程领域发展的早期阶段,Windows程序员唯一可用的编程工具是API(应用程序编程接口)函数。这些函数是Windows向应用程序和操作系统提供的接口。它们就像“积木”。同样,您可以构建各种接口丰富、功能灵活的应用程序。因此,可以认为API函数是整个Windows框架的基石。它的下面是Windows操作系统的核心,上面则是一切华丽的Windows应用程序。

Windows API提供的功能可以分为七类:

2.1 基础服务(Base Services)提供对Windows系统中可用的基本资源的访问接口。例如:文件系统、外部设备、进程、线程以及对Windows 注册表的访问和错误处理。这些功能接口位于Windows下的kernel32.dll和advapi32.dll中。

2.2 图形设备接口(GDI)提供将图形内容输出到显示器、打印机和其他外部输出设备的功能。 gdi32.dll 位于Windows 下。

2.3 图形用户界面(GUI),提供诸如创建和管理屏幕以及最基本的控件(控件)(如按钮和滚动条)、接收鼠标和键盘输入以及其他GUI相关功能等功能。这些调用接口位于Windows下的user32.dll中。从Windows XP版本开始,基本控件和通用对话框控件(通用控件库)的调用接口都放在comctl32.dll中。

2.4 通用对话框库为应用程序提供标准对话框,如打开/保存文档对话框、颜色对话框、字体对话框等。该链接库位于Windows 下的comdlg32.dll 中。它被分类在用户界面API 下。

2.5 通用控件库为应用程序提供了访问操作系统提供的一些高级控件的接口。如状态栏(status bar)、进度条(progressbars)、工具栏(toolbar)和标签(tab)等。这个链接库位于Windows下的comctl32.dll中。它被分类在用户界面API 下。

2.6 Windows Shell(Windows Shell)作为Windows API的组成部分,不仅允许应用程序访问Windows Shell提供的功能,而且还对其进行了改进和增强。它位于Windows 下的shell32.dll(Windows 95 上的shlwapi.dll)中。它被分类在用户界面API 下。

2.7 网络服务(Network Services)提供访问操作系统提供的各种网络功能的接口。它包括NetBIOS、Winsock、NetDDE和RPC等。

3 从API到可视化编程

想要编写Windows风格的软件的程序员必须使用API,API因此被赋予至高无上的地位。然而,如果没有合适的Windows编程平台,Windows开发是一项非常复杂的任务。在可视化编程IDE出现之前,当时的Windows程序开发还是一个比较复杂的任务。程序员必须记住很多常用的API函数,而且还必须对Windows操作系统有深入的了解。然而,随着软件技术的不断发展,Windows平台上出现了许多优秀的可视化编程环境。程序员可以采用“所见即所得”的编程方法,开发出用户界面精美、功能强大的应用程序。

这些优秀的可视化编程环境操作简单、界面友好(如VB、VC++、DELPHI等)。这些工具提供了大量的类库和各种控件。它们取代了API 的神秘功能。事实上,这些类库和控件都是建立在WIN32 API函数的基础上的,是封装的API函数的集合。它们将常用的API函数组合到一个控件或类库中并方便使用,从而大大加快了Windows应用程序的开发进程。有了这些控件和类库,程序员就可以专注于程序整体功能的设计,而不必过多关注技术细节。

4 API编程适应场合

事实上,如果我们想要开发更加灵活、实用、高效的应用程序,就必须涉及到API函数的直接使用。虽然类库和控件使应用程序开发变得更加简单,但它们只提供了Windows的一般功能,利用类库和控件来实现更复杂和特殊的功能是非常困难的。这种情况下就需要使用API函数来实现。

这也是API函数的使用地方,所以我们在对待API函数的时候,不必刻意去研究每个函数的用法,这也是不现实的(可以使用的API函数有上千个)。正如某位大虾所说:不用学API,需要的时候查看API帮助就够了。然而,许多API函数难以理解,容易误用,并且会导致错误,这些都阻碍了其推广。

5 从API到MFC

Windows API有数千个,每个API似乎都有相同的权重(至少你从手册中看不出来)。某些API 组合在一起,但没有相似或有组织的函数名称。星星散落各处,雾气如雪球一般。它越滚越大,越滚越大。编写Windows 应用程序需要大量的耐力和毅力,并且需要非常谨慎!

MFC帮助我们使用面向对象的原则在逻辑上组织这些众多的API,使它们抽象、封装、可继承、多态和模块化。

1989年,微软成立了一个应用程序框架技术团队,称为AFX团队,开发C++面向对象的工具,供Windows应用程序开发人员使用。 AFX中的“X”实际上没有任何意义,只是为了起一个响亮且易于发音的名字。

据记录,该组织最初的“章程”是“利用最新的面向对象技术,为开发人员编写市场上最先进的GUI 应用程序提供工具和库”,其范围并不局限于Windows 操作系统。系统。果然,它的第一个原型产品有自己的窗口系统,自己的绘图系统,自己的对象数据库,甚至自己的内存管理系统。当团队成员使用该产品开发应用程序时,他们发现它太复杂,并且与公司的主流系统Windows相差太远。因此,他们修改了章程,“向程序员提供面向对象解决方案的强大功能,使他们能够用C++ 构建世界一流的基于Windows 的应用程序。”这大约是Windows 3.0突然出现的时候。

C++ 是一种复杂的语言,AFX 团队预计并非每个使用MFC 的人都会成为C++ 专家,因此他们不会使用C++ 的所有高阶功能(例如多重继承)。许多“麻烦”但“几乎不变”的Windows程序动作都隐藏在MFC类中,例如WinMain、RegisterClass、Window procedure等。

为了让MFC尽可能的小和快,AFX团队不得不放弃高度抽象(导致虚函数过多),而引入自己发明的机制来尝试解决面向对象中的Windows消息处理问题。场地。问题。这就是消息映射和消息路由机制。请注意,他们没有改变C++ 语言本身,也没有扩展该语言的功能。他们只是设计了一些令人惊叹的宏,而这些宏的背后隐藏着一个巨大的机制。

微软在1992/04年推出C/C++ 7.0产品时首次向世界推出了MFC 1.0。这个早期产品包含20,000 行C++ 源代码、60 多个Windows 相关类别以及时间等其他常规类别。数据处理、文件、内存、诊断、字符串等。它提供的实际上是“Windows API 的精简且高效的C++ 转换”。其32 位版本也于1992/07 年随Win32 SDK 一起推出。

MFC实现了控件的可视化,其应用程序向导和类向导可以实现程序和代码模块框架的自动化执行。

开发需要读写文件并具有简单输入和输出的应用程序可以利用单文档视图结构。

开发专注于交互的简单应用程序可以使用基于对话框的窗口。如果文件读写比较简单,可以使用CFile来完成。

当需要在多个文档之间传递数据时,请使用多文档视图结构。

6 图形界面程序中的资源

资源使用Windows API 中的特殊结构指针和句柄进行引用。

Windows API开发的时候,C++还没有出现,所以Windows提供的API函数使用的封装数据类型是结构体(而不是类)。随着C++的诞生和普及,Windows API+C++催生了MFC,资源控制开发可视化,封装的数据类型也使用类类型来实现。

常用资源:ICON、CURSOR、BITMAP、FONT、DIALOG、MENU、ACCELERATOR、STRING、VERSIONINFO、TOOLBAR。

7 图形界面程序中的事件与消息

Windows API 允许程序员连接消息和响应函数。 MFC是程序员使用微软为我们准备的MESSAGE-MAP机制来处理消息的。

8 函数库和类库

Windows API 和MFC 都使用.lib 文件。

.lib 有两种类型。一是.lib文件包含cpp编译的代码。链接时,将所需代码复制到exe中。 Mfc、crt在选择static时使用此方法。

另一种是.lib不包含代码,只是描述了要查找哪个dll以及如何查找对应的代码。这个编译好的exe需要dll才能运行。这就是mfc 和crt 使用共享库以及Windows API 的方式。

API的dll在Windows系统的system32目录下,与图形界面相关的API在USER32.dll中,进程、文件等操作在kernel32.dll中。 MSDN中的每个函数都会解释它在哪个头文件、哪个lib、哪个dll中。

9 C、C++控制台程序、Windows API程序、MFC程序比较

C++ 不是纯粹的面向对象语言(SmallTalk 和Java 是)。因此,MFC中存在不属于任何类别的全局函数。它们的函数名开头都带有Afx 前缀。

类的继承性在MFC的控件类中体现得最为充分。在MFC中,已经建立了各种控件类的框架,其中包括最常用的属性和方法以及一些虚函数。开发人员可以重复编写虚函数或派生控制类来实现自己的功能或个性化需求。

用户评论

入骨相思

终于有个地方认真地解释了 C/C++ 控制台程序、Windows API 程序和 MFC 程序的区别!以前一直都混淆这些概念,这篇文章读完感觉豁然开朗,现在我能更好地理解自己学习的目标了。

    有18位网友表示赞同!

日久见人心

我一直觉得 Windows API 比 MFC 简单一些,因为更直接地操控系统资源。但文章的对比让我更加清晰地认识到 MFC 的优势在于它封装了很多繁琐的操作,方便快速开发应用程序。

    有14位网友表示赞同!

伪心

没经验的人看这篇文章估计一头雾水啊。我花了五年才从 C/C++ 控制台程序摸索到 Windows API,现在开始学习 MFC 了。希望可以早日掌握这三种编程方式的不同之处!

    有13位网友表示赞同!

微信名字

想问一句,如果要开发大型应用程序,用哪种方式比较合适呢?感觉 MFC 比其他两种方式效率更高,但又担心过于依赖框架

    有11位网友表示赞同!

采姑娘的小蘑菇

我一直在纠结要不要学习 Windows API。看了篇文章后,我觉得 C/C++ 控制台程序还是太基础了,直接跳到 Windows API 能更系统地掌握一些 Windows 原理,MFC 可以以后再学。

    有13位网友表示赞同!

挽手余生ら

这个标题真是太吸引人了!以前我对这三种编程方式的了解都停留在模糊的概念上,现在终于能清晰地对比了,感觉学习目标更加明确了。感谢作者用心制作的文章!

    有19位网友表示赞同!

江山策

文章写的比较浅显易懂,对于初学者来说可以作为入门指南参考,但对于有些经验的开发者来说可不够全面。我希望能看到更深入的分析和比较。

    有5位网友表示赞同!

看我发功喷飞你

我一直觉得这三种编程方式都很有用,只是用途不太一样罢了。不过感觉 MFC 这种封装式的开发模式确实更适合快速构建一些GUI应用程序。

    有13位网友表示赞同!

烟雨离殇

我觉得 C/C++ 控制台程序是一种必备的基本技能,因为它可以帮助我们理解计算机是如何工作的,而 Windows API 更注重实际操作系统的能力。MFC 则是更高层的框架,可以更快地实现一些复杂的功能。三种方式各有优劣,需要根据具体的项目需求来选择合适的方式。

    有16位网友表示赞同!

凝残月

这篇文章写得真好!终于有人能让我明白 C/C++ 控制台程序和 Windows API 的区别了!我之前还一直以为它们是一模一样呢

    有10位网友表示赞同!

浮光浅夏ζ

感觉 MFC 越来越少人用了吧?现在的开发趋势是往平台无关性以及更现代的框架去发展。这篇文章也应该多关注一下新的技术发展方向。

    有11位网友表示赞同!

孤岛晴空

我想学做 Windows 程序,该从那开始比较好呢?我现在只会 C/C++ 控制台程序,感觉太基础了,想要快速上手 Windows 开发...

    有7位网友表示赞同!

失心疯i

对于初学者来说,学习 MFC 的确比较容易,它封装了许多系统接口,可以快速上手开发。但是后期维护可能会因为框架过于封闭而有些困难。

    有8位网友表示赞同!

莫名的青春

文章里提到的三种编程方式各有优缺点,需要根据实际情况选择合适的方式。我觉得 Windows API 学习起来相对复杂一些,需要对操作系统原理有比较深入的理解.

    有17位网友表示赞同!

£烟消云散

我个人的经验是,C/C++ 控制台程序适合开发独立运行的小程序,Windows API 更适合开发与系统交互的功能性应用程序,MFC 用于构建桌面GUI应用。这三种方式各有千秋啊!

    有20位网友表示赞同!

热点资讯