编程达人、爱达人
在当今基于C++的图形界面开发领域，能与Qt相抗衡的也只有MFC，MFC是微软公司的基础类库，自然得天独厚，比如开发深层次的Windows应用，MFC当然远超Qt，但Qt也有杀手锏，那就是跨平台。这两点大家一目了然。下面我们再来比较它们的其他特点。
（1）开发速度
就整体而言，MFC可能会快捷一些，因为Windows平台的开发工具大多很智能，因为立足于Windows的开发人群很广，从菜鸟到专业人士（开发人员一多，技术参考就多，周围可以咨询问题的人就多）。相比较而言，Qt基于Linux，可用的开发工具不多，而且这些工具大都比较专业，多是第三方的产品，加上这些工具的集成度不高，支持的第三方库也没有支持MFC的第三方库多，因而从这一点看，MFC略胜一筹。不过，Qt自从被诺基亚公司收购后，官方发布了跨平台集成开发环境Qt Creator，之后的走向就不好说了，作者个人的总体感觉是Qt Creator和VS差距比较大，还需要改进。
从库本身来说，Qt集成的功能比MFC庞大，而且使用的封装技术（信号/槽）倍受赞许，比如Qt Script为Qt提供了嵌入式脚本，Qt界面库支持CSS，所以Qt构建出来的界面比MFC要好，且实现过程也比较容易。为了降低使用Windows SDK开发的难度以及提高使用Windows SDK开发的效率，MFC采用的是浅层封装（最新的2008 sp1加入了BCG的高级界面库，可能有所改善）Windows SDK。这个方面相比而言，Qt库比MFC优秀。不过，这两个库都久经时间的考验，稳定性都很高，几乎没有什么Bug。
（2）运行效率
MFC采用浅层封装，运行效率比较高，加上VC对Windows进行了针对性的优化，因而整体性能是比较高的，但是如果加入第三方库就不敢保证整体的高性能了。Qt库比较庞大，封装层次较深，所以运行效率比MFC低，但是在如今主流计算机系统的配置下，人们还会介意这点性能差别吗？（反正大家都不介意C#对性能略微拉低的影响了。）
（3）应用范围
如今Windows的普及率无人能及，MFC的使用人数自然就多，相比而言，Qt主要是Linux下的开发人员在使用。MFC不支持嵌入式开发（主要是指手机平台），而Qt有对应的支持模块，虽然这一手机开发领域被Java碾压，但总归还是有Qt的使用空间。
（4）学习难度
Qt的封装方式比较明晰，和系统隔离得比较好，作者个人觉得学习的门槛不高。而MFC则较难精通，因为深入开发之后还需要了解SDK，否则开发出的程序比较初级。
（5）伪对象vs真对象
归根结底，Qt和MFC的差异在于其设计的差异。MFC的根本目的是让开发者调用封装好的、用C语言编写的Windows API。但是，这绝非好的面向对象的程序设计模式，因为在很多场合，我们必须提供一个包含15个结构成员的C语言的struct（结构类型），但是其中只有一个结构成员是我们需要使用的，或者必须用在调用函数中使用参数的方式来获得我们需要的结构成员。MFC还有许多让人摸不着头脑的地方，例如函数名没有任何连续性，假如我们创建了一个graphical类，直到调用了creat()以后该类才会被创建。然而对于dialogs类，必须要等到调用OnInitDialog()才能创建这个类的实例对象。奇怪的是到了views，创建该类的函数名竟然成了OnInitUpdate()，使用VC/MFC中的库函数调用总是要十分小心，不如Qt那样一看函数名就知道对应函数的作用是什么。
（6）消息循环
MFC是事件驱动的架构。必须对任何操作对应的特定消息做出响应。Windows中应用程序发送的信息数以千计，遗憾的是，要厘清这些纷繁芜杂的消息很困难，通过参考这方面的文档资料并不能很好地解决这些问题。
Qt的消息机制建立在SIGNAL()发送和SLOT()接收的基础上。这个机制是对象间建立联系的核心机制。利用SIGNAL()可以传递任何参数，它的功能非常强大，可以直接传递信号给SLOT()，因此可以清楚地理解要发生的事情。一个类所发送的信号数量通常非常少（4个或者5个），相关的帮助文档资料也非常齐全。这让我们会觉得到一切尽在掌握之中。信号/槽（Signal/Slot）机制类似于Java中的listener机制，不过这种机制更加轻量级，功能更齐全。
（7）创建界面
MFC无法创建大小动态可变的子窗口 ，必须重新手动修改代码来改变窗口的位置（这恰好解释了为什么Windows里的对话框dialog是不可以改变的），这个问题在软件进行多语言化版本设计时更加严重，因为许多国家或地区在表达相同意思时可能需要更长的词汇和句子，于是软件开发者必须对每种语言的版本重新修改自己的软件。
在Qt中，界面需要的任何设计都可以手动编写出来，因为它很简单：为了得到一个按钮（button），可以将代码写为“button = new PushButton( "buttonName", MyParentName );”，如果想在按下某个按钮以后调用某段执行代码，则可以编写为“connect(button, SIGNAL(clicked()), qApp, SLOT(action()));”。Qt拥有非常简单而又不失强大的设计机制，不使用它实在可惜。
Qt还提供了一个图形用户工具——Qt Designer，可以用来协助建立用户界面。可以使用Qt Designer修改所使用的任何控件的属性，不用将这些控件拖放到设计严格限定的位置，因为可以通过设计机制更完美地组织这些控件。
Qt Designer这个工具所生成的代码可阅读、可理解。所生成的代码单独放在一个文件中，在编程的同时，我们可以随心所欲地多次重新生成用户界面。
Qt Designer可以让我们完成许多在MFC中不可能完成的任务，比如用预先填好的内容生成列表视图（listview），在每个页签（tab）上使用不同的视图（view）。
（8）帮助文档
用户选择图形开发环境的时候，帮助文档是否周全是左右用户选择图形开发环境的重要因素。Visual开发环境的帮助文档MSDN（这个还要单独掏钱购买）非常庞大，有10个CD-ROM光盘容量之大，它包罗万象，涵盖广泛，但难免有泥沙俱下、主题模糊、关键信息不突出的遗憾。MSDN的链接设计也很糟糕，通过链接很难从一个类跳转到它的父类或者子类以及相关的类。如果搜索一个关键字，结果找到的内容不管是否直接关联，只要包含这个关键字的信息统统都会搜索出来，让用户再从中选择。
Qt的文档设计得相当优秀，可以到https://doc.qt.io/上面一睹它的芳容。Qt的文档完备且详细地覆盖了Qt的方方面面，然而文档的整体容量竟然仅有18MB。其中每一个类和方法都被详尽描述，巨细靡遗，举例充实。通过Trolltech公司提供的链接或者是Qt Assistant工具可以方便地从一个类或者方法跳转到其他的类。文档还包含了一个初学者教程和一些典型应用的例子。同时还提供了FAQ和邮件列表，方便用户通过用户群或通过Internet来查阅。如果我们购买了授权，在一天之内就会得到Trolltech公司的技术支持。实际上，Qt优秀的帮助文档使得寻求外部帮助的机会大大减少。Trolltech公司的宗旨之一是：有如此优秀的Qt产品及其帮助文档，其他外部的技术支持就是多余的。
总之，MSDN用熟了也很好用、很全面，相关的背景知识、例子都能找到，而且网上还有丰富的范例程序可以参考。同样的，仅凭Qt的帮助文档也绝对不足以解决所有问题，以作者的亲历，在网上只找到了一个Qt中文论坛，提过几个问题，有的问题给出了解决办法，有的问题则没人回答，最后还要靠自己试。
（9）Unicode编码
使用MFC，如果要显示Unicode编码的字符，在编译链接时必须用到特殊的参数（还要改变可执行文件执行的入口），必须在每个string前面加上T，将char修改成TCHAR，每个字符串处理函数（strcpy()、strdup()、strcat()等等）都要改变成另外的字符串处理函数名。更令人恼火的是，支持Unicode的软件竟然不能和不支持Unicode编码的DLL一起工作。这是一个很严重的问题，但是我们却别无选择。
使用Qt，字符串用QString类来处理，QString类与生俱来就采用Unicode编码，因而不需要改变任何东西：不需要在编译/链接时增添参数，不需要修改代码，只需要使用QString类即可。QString类功能强大、应用广泛，也不用担心Unicode问题。QString类提供了转换为char * 和UTF8的函数。MFC的CString类设计相比于Qt的QString类设计则有着巨大的不同，CString类以char *为基础提供的功能很少，它的特点是当需要char *类型时，可以直接使用CString类。乍看起来这好像是个优点，实质上有很大缺陷，特别是可以直接修改char *内容而不用更新类，在转变为Unicode时就会遭遇到很大的麻烦（CString类随编译选项可以是Unicode版）。相反，QString类在内部以Unicode编码方式来存储字符串，需要时提供char *功能，实际上很少用到char *，因为整个Qt的API用文本的方式响应QString参数。QString还附带了许多其他的功能，比如自动分享QString的内容。总之QString是一个非常强大的类，需要用到它的地方很多。
（10）支持软件的多语种功能
MFC可以支持软件的多语种功能，需要将每一个语种的字符串放在一个字符串表中，在代码中需要之处调用LoadString(IDENTIFIET)，然后把这些字符串资源转化到DLL中，这些字符串对应到所需要的语言，改变图形界面，再通过程序调用这个DLL。整个过程是如此的烦琐，可谓牵一发而动全身。
Qt支持软件多语种的方式有所不同，只需要将字符串置于函数tr()中，可以直接在代码中改变字符串的引用。Qt Linguist（Qt的一个工具）能够提取所有待翻译的字符串并按照对应语种的用户界面显示出来，这个工具非常适合进行用户界面的多语种翻译，它功能齐全：通过查询字典数据显示出对应语种的字符串内容，正确显示出Unicode编码，以快捷方式检测出未翻译的字符串，检测字符串修改的情况。这个工具甚至可以提供给没有任何编程经验的翻译人员用于翻译软件的用户界面。该软件的发布遵循GPL版权规则，开发者可以根据具体的开发需求来修改它。翻译之后的文档保存在XML中，符合软件复用的原则。由此可见，为软件增加一种新的语言版本仅仅是用Qt Linguist工具生成一个新的文件而已。
（11）资源问题
使用MFC时，一部分开发过程要依靠“资源”（resources），在很多的案例中开发者都必须使用它们。这样会导致如下后果：除了Visual Studio，很难使用其他的工具来完成开发。资源编辑器仅有有限的功能，比如通过Dialog编辑器不能改变所有的属性。
然而，Qt并没有资源的概念，这就解决了MFC所遇到的问题。Qt提供了一个界面设计器以可视化的方式来设计界面，并把设计后生成的代码存储到一个脚本文件中。
（12）价格
用户一旦购买了Visual Studio，将免费获得MFC SDK。Qt在UNIX上可以免费获得遵守GPL版权规则的版本（现在可以免费获得Windows平台上的GPL版本）。如果要开发不公开源代码的软件，则必须购买Qt的授权。在特定平台下，每个开发者购买一个永久性授权，并可获得一年的技术支持。
（13）发布
在发布基于MFC的软件时，必须依靠存储在客户计算机上的MFC，但是这是不安全的，同样是MFC42.dll，基于相同的库可得到3个不同的版本。因而需要检查是否拥有正确的MFC42.dll版本，如果版本不对，就升级它。但是，升级MFC42.dll会改变很多软件的行为。这让开发者感到很不“爽”，如果用户在安装软件以后导致用户的计算机死机了，该怎么办呢？
Qt则没有这个风险，因为Qt压根就没有“升级整个系统”的概念。不过，如果开发的软件不是基于同一个版本的Qt来运行，还是会有潜在的问题。