本文将为大家讲解关于MFC编程实例中Qt VS MFC，通过MFC编程实例的内容让你对相关知识点有进一步的认识和理解!

帮助文档

用户选择图形开发环境的时候，帮助文档是否周全是左右其选择的重要因素。Visual开发环境的帮助文档MSDN(这个还要单独掏钱购买)非常的庞大，有10个CDROM光盘。它包罗万象，涵盖广泛。但是难免有泥沙俱下，主题模糊，关键信息不突出的遗憾。其链接设计的也很糟糕，通过链接很难从一个类跳转到其父类或者子类以及相关的类。如果你搜索一个关键字，不管是Visual C++、Visual J++、Visual Basic，只要包含这些关键字的信息统统的返回来。

Qt的文档设计的相当优秀，其文档完备且详细的覆盖了Qt的方方面面，竟然仅有18M。每一个类和方法都被详尽描述，巨细靡遗，举例充实。

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时这个也碰到很大的麻烦。（CString随编译选项可以是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编辑器不可能改变所有的属性，一些属性可以改变，另一些属性则不可能改变。

然而Qt并没有资源的概念，这就解决了以上所提到的问题。Qt提供了一个脚本使得能将其编入你的代码中。对于界面设计，Qt Designer则创建了可读的代码。

发布

在发布基于MFC的软件时，必须依靠存在于客户电脑上的MFC。但是这是不安全的，同样是MFC42.dll，可以基于相同的库得到3个不同的版本。通常，需要检查是否拥有正确的MFC42.dll版本，如果不是，就升级它。

Qt则没有这个风险，因为Qt压根就没有“升级整个系统”这个概念。

速度

MFC是专为Windows设计的，而Qt是跨平台的。所以MFC编写的程序的运行速度、响应时间都优于Qt。

希望这篇MFC编程文章可以帮助到你。总之，同学们，你想要的职坐标MFC频道都能找到!