MFC过时了吗？初学者远离？QT取代？QT/MFC对比

刚刚拜读了一个博主写的文章，想起了自己曾经的学习历程，有感而发；

https://blog.csdn.net/weixin_33726313/article/details/85961406
本人2019年开始系统学习计算机，从C语言开始学习，是从linux系统上学习的，之前从未接触过linux系统，觉得很感兴趣；然后学习uinx系统编程（这门课程包括了很多东西，计算机组成原理，编译原理，内存管理，网组，计组，软工等等），然当时对网络比较感兴趣，决心要干linux下的编程，纯C语言的开发，印象深刻当时uc的老师说了一句话“总有一群sb觉得C++比C牛逼”，还有一句话，是第一课时讲的，说“我这门课就是九阳神功，是内功，至于什么你们之后学习的什么语言啊框架啊，那都是招式，内功不足，在花里胡哨也是徒有其表”，现在想想是这样的，学了这门课之后，后面学的，都可以用已经掌握的系统知识来分析，比如c++的生命周期和作用域，学过内存管理，代码段啊，数据段啊，栈，堆等等，轻而易举就可以理解，不需要死记硬背，理解分析就好；
之后接触到了C++，C98，也是在linux，学了就真香了，当时比较懵懂，觉得c++真的是很神奇，很有意思，确实也有一定的难度，当时很懵懂，自己好像要成为那个sb了，觉得c++比c牛逼了，开玩笑，其实都知道，c语言才是祖宗，又真香了，想干C++了；
之后学习了qt，终于见到界面了，哇，真有意思，各种类库都封装好了，qt助手文档齐全，做出来的界面漂亮，而且跨平台，当时学的时候，也是在linux下的Qt creator，也用qt做了些小游戏，例如俄罗斯方块等等，主要很简单，就是信号和槽函数，事件驱动，初学者容易接受，这又深深吸引我了；
之后学习了win32,核心编程，就是windows下的c语言，界面编程，windows下的api函数；
最后到了MFC，mfc第一节课老师问，qt和mfc有什么区别啊？最后老师说如果程序需要跨平台，那你首选qt；如果只是在windows下，那你首选mfc；我们mfc是从底层开始讲起的，跟了底层的代码，看到了封装起来的主函数入口，理解了消息链，消息映射，钩子函数等等，底层代码确实很复杂，这时班里已经多半放弃了，都开始专心去复习qt了，可是我觉得很有意思，也没那么难，看了底层代码觉得微软这些程序员真的厉害，写出这么巧妙地代码，一直跟着学到了最后，课上的例子我自己课下基本都拿qt做了一遍，其实差不了多少，各有各的优点，我qt学的也不错，但是就是对mfc不知道哪来的那份执着，就是喜欢，可能是跟了底层的代码觉得很有意思吧，对话框交换技术，消息映射等等真的挺好玩的；后来，其实我知道mfc俗称没饭吃，甚至我的老师，忠实的微软追随者，他都劝我不要找mfc的工作，你qt学的不错，找个qt的吧，mfc需要的话你也会，没问题的，但是我真的不知道为啥，就想找mfc的，我当时就是初学者，可能我像文章里说的那样sb吧；其实就像我学习的过程一样，不断接触新的知识，你就会觉得这个好，那个也好，不过你总要找自己喜欢的，适合自己的才最重要；但是有了新的语言，框架，你都要学，不能说我不感兴趣，再流行老子也不学，那哪行，那也许早晚会被it行业淘汰，这个行业就是一个一辈子都要学习的行业；而且像我上面说的，一定要有扎实的基本功，比如我说的九阳神功；掌握了基本功，什么语言框架都是如虎添翼，是你选择编程语言，而不能让编程语言或者语言的更新迭代来选择你影响你；
总有人拿qt和mfc相比，有什么好比的，都是基于c++，只不过是两家公司开发的两款框架而已，mfc比较早，现在渐渐的过气了，局限性慢慢的出来了；你敢保证多年之后，qt不会重蹈mfc的覆辙吗？当年诺基亚多么牛逼，不也是被淘汰了吗？mfc就算过时，也不会死的，总会有需要的地方，很多大公司遗留下的产品项目，都是mfc来维护的，不会轻易就没了的，而且很多程序开发，你用mfc就是最合适的，再而且其他能做的程序，mfc基本都可以完成；都是为了混一口饭吃，有的人喜欢用原理来喷这个不好那个不好，可能你真的懂原理，那你开发的时候，用得到吗？用到的多吗？你就负责满足用户的需求就好了；
mfc没饭吃，学了不会让你饿死的；初学者，我建议如果你可以尝试下跟mfc底层代码，如果你能跟下来，能大概掌握，那你就学完他，浪费不了你多长时间，即使没用，多掌握一门语言，总是不吃亏的；如果你真的觉得太难了，那你可以尝试其他的框架开发，比如qt啊，简单，手册齐全；也许你学完了qt再回头想想mfc，其实也就那么回事了，套路都是一样的；mfc就是消息映射，qt就是信号和槽连接；我就是现学的qt，让我学习起来mfc也没觉得多难，边学边比较，知道两者都区别，各自的优缺点，这样以后你不管干什么都可以，两个老子都会，他不香吗？多学点东西，就多一份选择；加油吧，我的程序员朋友们；

下面附上qt和mfc对比（转载）
我曾经使用过QT和MFC来开发过软件，我想和大家分享我使用他们时所体会的不同之处。
我并非一个职业作家，这篇文章可能看起来不如专业的杂志和网站上的那么条理清晰。但是，我在这里是用我自己的语言来表达我自己的经验，希望能和你分享。英语比不是我的母语，所以可能会有一些用词古怪，词句错误之处，请发信给我，我可以改正他们。
本文不想假装客观公正，我只想表述我使用的经验。文中不会逐条的列举Qt和MFC各自的优缺点。我在使用MFC之前就已经使用Qt这个事实可能影响了我的客观性。
文章从实用主义的观点出发：我的老板给我一份软件的规划说明，并且让我来开发。其中一些我用Qt来开发，而另外一些我使用MFC来开发。
MFC（微软基础类库）是专门为windows设计的一个用于开发图形用户界面的类库。MFC或多或少使用了面向对象的方法包装了Win32的API，正因如此，这些API有时是C++，有时是C，甚至是C和C＋＋的混合体。
Qt这个C++的图形库由Trolltech在1994年左右开发。它可以运行在Windows,Mac OS X, Unix，还有像Sharp Zaurus这类嵌入式系统中。Qt是完全面向对象的。

Document/View model
MFC编程需要使用Document/View模式以及模板(template),如果不使用的话，编程将变得异常困难。而且，模板(template)设定了固定的结构，若所需结构乃模板未定义之结构，则编程难已。例如，划分一区域使显示两个视图(view)于两个文档(document)。还有一个经常的问题是：模板(template)创建了视图(view)却无法访问(access)它，文档（document）要做完所有事情，但是这经常会出现问题。
Qt不强制使用任何设计模式。如果你认为恰当，使用Document/view没有任何问题。不使用也没有任何问题。
伪对象 vs 真对象
归根结底，Qt和MFC的差异在于其设计的差异。
MFC的根本目的是访问包装起来的用C语言写的windows的API。 这绝非好的面向对象的设计模式，在很多地方，你必须提供一个包含15个成员的C语言的struct，但是其中只有一个与你所期望的相关，或者必须用旧式的参数来调用你的函数。
MFC还有许多让人摸不着头脑的地方，函数名没有任何的连续性。比如，如果你创建了一个graphical类，直到调用了creat()以后该类才会被创建。然而对dialogs，必须要等到OnInitDialog()才能创建这个对象。奇怪的是到了views,创建该类的函数名竟然成了OnInitUpdate(),…你自己创建一个类用他们的方式调用它，你的程序崩溃了。
比如说有一个dialog包含CEdit控件，如果没有调用DoModal()你就不能使用GetWindowText()。否则将会莫名其妙的失败。总之，MFC充满了丈二和尚摸不着头脑的事情，并且，这种错误很难调试。
Qt恰恰相反，它的架构明显是经过精心设计的面向对象的。Qt因此在命名，继承，类的组织等方面保持了优秀的一致性。你只需要提供唯一一个方法的参数，仅此一个。在不同的类中调用方式也是有很强的连贯性。返回值也很有逻辑性。所有一切达到了简单和强大的和谐统一。一旦你使用了其中一个类，其他的类也就触类旁通，因为他们是一致的。
在Qt中可以利用Edit控件，用C++创建类的方法来创建自己的QLineEdit。永远可以马上访问任何的方法，不管它是显示还是隐藏。在这里没有迷局，一切都按照你认为的简单的方式来运作。
消息循环
MFC是事件驱动的架构。要执行任何操作，都必须是对特定的消息作出响应。Windows对应用程序发送的
信息数以千计，遗憾的是，要分清楚这些分繁芜杂的消息是很困难的，并且关于这方面的文档并不能很好的解决这些问题。
Qt的消息机制是建立在SIGNAL()发送和SLOT()接受的基础上的。这个机制是对象间建立联系的核心机制。利用SIGNAL()可以传递任何的参数。他的功能非常的强大。可以直接大传递信号给SLOT()，因此可以清楚的理解要发生的事情。一个类所发送的信号的数量通常非常的小(4或者5)，并且文档也非常的齐全。这让你感觉到一切尽在掌握之中。SIGNAL/SLOT机制类似于Java中listener机制,不过这种机制更加轻量级，功能更齐全。
创建界面
MFC无法创建大小动态可变的子窗口 ，必须重新手动修改代码来改变窗口的位置（这恰好解释了为什么windows里的dialog是不可以改变的）这个问题在软件进行国际化翻译的时候更加严重，因为许多国家表达相同意思需要更长的词汇和句子，必须要对每个语言的版本重新修改自己的软件。
在Qt中，任何东西都可以手动的敲出来，因为它很简单：为了得到一个button，可以这样些
button = new PushButton( “buttonName”, MyParentName );
如果想在按下某个按钮以后想调用某断代码的执行，可以这样写：
connect( button, SIGNAL( clicked() ), qApp, SLOT( action() ) );
Qt拥有非常简单而又不失强大的layout机制，以至于不使用它就是在浪费时间了。
Qt还提供了一个图形用户工具，Qt Designer，可以用来帮助建立用户界面。可以修改所使用的任何控件的属性。不用将他们放在严格的位置，可以通过layout完美的组织他们。这个工具所产生的代码我们是可以实际上阅读并且可以理解的。生成的代码单独放在一个文件里，在编程的同时，你可以随心所欲的多次重新生成用户界面。
Qt Designer可以让你完成许多在MFC中不可能完成的任务，比如用预先填好的生成listview，在每个tab上用不同的view来使用tab 控制。
帮助文档
用户选择图形开发环境的时候，帮助文档是否周全是左右其选择的重要因素。Visual的开发环境的帮助文档MSDN(这个还要单独掏钱购买)非常的庞大，有10个CDROM光盘。他包罗万象，涵盖广泛。但是难免有泥沙俱下，主题模糊，关键信息不突出的遗憾。其链接设计的也很糟糕，通过链接很难从一个类跳转到其父类或者子类以及相关的类。如果你搜索一个关键字，不管是Visual C++, Visual J++, Visual Basic，只要包含这些关键字的信息统统的返回来。
Qt的文档设计的相当优秀。你可以到doc.tolltech.com上面一睹芳容。
Qt的文档完备且详细的覆盖了Qt的方方面面，竟然仅有18M。每一个类和方法都被详尽描述，巨细靡遗，举例充实。通过Trolltech公司提供的链接或者是Qt Assistant工具，可以方便的从一个类或者方法跳转到其他的类。文档还包含了一个初学者教程和一些典型应用的例子。同时还提供了FAQ和邮件列表，方便通过Internet或者用户群来查阅。如果你购买了授权，在一天之内你将会得到Trolltech公司的技术支持。
实际上，Qt优秀的帮助文档使得寻求外部帮助的机会大大减少。Tolltech公司的一个宗旨是：有如此优秀的Qt产品以及其帮助文档，技术支持是多余的。
Unicode
使用MFC，如果要显示unicode，在编译链接的时候必须用到特殊的参数(和改变可执行文件执行的入口)，必须在每个string前面加上T，将char修改成TCHAR，每个字符串处理函数(strcpy(), strdup(), strcat()… )都要改变成另外的函数名。更令人恼火的是支持Unicode的软件竟然不能和不支持Unicode的DLL一起工作。当使用外部DLL来开发的时候这是个很严重的问题，但是你毫无选择。
使用Qt，字符串用QString来处理，其本身是与生俱来的Unicode.不需要改变什么东西。不要在编译/链接时候增添参数，不要修改代码，只需要使用QString就可以了。
QSting类功能强大，你可以广泛的使用它，并且不要担心Unicode问题。这使得转换为Unicode非常的方便。QSting提供了转换为char ＊ 和UTF8的函数。
显然，MFC的CString的设计相比于Qt的QString设计有着巨大的不同。CString以char ＊为基础提供了很少的功能。它的优点是当需要char ＊类型的时候，可以直接使用CString类型。乍看起来这个好像是个优点，其实实质上还是有很大的缺陷的，特别是可以直接修改char * 而不要更新类。在转变为Unicode的时候这个也碰到很大的麻烦。
相反，QString在内部以unicode存储string，需要时提供char ＊功能。实际上很少用到char ＊，因为整个Qt的API用文本的方式响应QString参数。QString还附带许多其他的功能，比如自动分享QString的内容。这是一个非常强大的类，你会喜欢在很多地方用它的。
国际化
使用MFC是可以国际化的，但是需要将每一个字符串放在一个字符串表中，在代码中到处使用LoadString(IDENTIFIET)。然后转化这些资源到DLL中，翻译字符串到所需要的语言，改变图形界面，然后调用程序使用这个DLL。整个过程是如此的繁琐，可谓牵一发而动全身。考虑的事情要面面俱到。
使用Qt的时候，只需要将字符串置于函数tr()中，在程序开发中这算是举手之劳。可以直接在代码中改变字符串的参考。Qt Linguist,Qt的一个工具，能够提取所有待翻译的string并按照友好的界面显示出来。这个用户界面非常适合翻译，使用字典，显示字符串内容，恰当的unicode显示，快捷方式冲突检测，检测未翻译的字符串，检测字符串修改情况，功能齐全。这个软件可以供没有任何编程经验的翻译者使用。同时该软件在GPL的版权下发布，可以按照你的需求来修改它。
翻译以后的文档保存在XML中，适合软件复用的原则。为软件增加一种新的语言版本仅仅是用Qt Linguist产生一个新的文件而已。
resources问题
使用MFC，一部分开发过程要依靠“resources”,在很多的案例中开发者必须使用他们。这样会导致如下的后果：
出了Visual Studio，你很难使用其他的工具来完成开发。
资源编辑器仅有有限的功能，比如：通过Dialog编辑器不可能改变所有的属性，一些属性可以改变，另一些属性则不可能改变。(译者注：下面还有两条陈述MFC缺点的实例，但我感觉这些已经够说明问题了，暂时删节不译)
然而Qt并没有资源的概念，这就解决了以上所提到的问题。Qt提供了一个脚本使得能将编入你的代码。对于界面设计，Qt Designer则创建了可读的代码。
价格
一旦你购买了Visual Studio，你将免费的获得MFC SDK。
Qt在Unix上是可以免费获得其遵守GPL版权的版本(译者注:现在在windows 上也可以免费获得其GPL版本)。如果要开发不公开源代码的软件，必须购买Qt的授权。在特定平台下，每个开发者购买一个永久性授权，并获得一年的技术支持。(译者注：后面关于购买价格等问题删去，因为价格不固定，如果有疑问请到官方网站查询价格)
发布
在发布基于MFC的软件时，必须依靠存在于客户电脑上的MFC。但是这是不安全的，同样是MFC42.dll，可以基于相同的库得到3个不同的版本。通常，需要检查是否拥有正确的MFC42.dll版本，如果不是，就升级它。但是升级MFC42.dll会改变很多软件的行为。这让我感到很不舒服，如果用户在安装我的软件以后导致其机器死机该怎么办？
Qt则没有这个风险，因为Qt压根就没有“升级整个系统”这个概念。