3544人阅读
编程语言的组成
编程语言做为一种语言自然和英语这些自然语言有类似的地方.学英语时我们知道要先记26个字母,然后单词及其发音,接下来就是词组,句子.反正简单的说就是记单词,熟悉词法,句法.接下来就是应用了,听说读写.而使用相同语言的人大脑里都有个翻译器,可以把自己的想法翻译成语言然后用说或写表达出来,而听和读则把接收来的语言翻译成自己大脑能理解的思想.
那编程语言首先也是像英语一样会制定一些单词,然后词法,句法.像int ,char这样的类型关键字,或其他一些关键字就是单词.但这样的语言机器不认识的.所以就要个编译器来翻译成电脑能认识的01串.编译器就像大脑中的翻译器了.所以简单的说起来,一些语法规则加一个编译器就可以标志一门新的编程语言产生了.但语言内置的的都是些非常基本的操作,你要实现个啥复杂点的功能得写很多很多代码,于是有些人就先把很多常用的操作写好代码放那,你以后只管去调用.造好了很多轮子等着你用就行.这就是开发一些库（library)让你调用.在面向对象的语言中一般就叫类库,就是一堆堆的类嘛.如果类库足够强大,我们也可以叫作框架.反正我们可以简单的把框架理解为一些功能强大并且联系紧密的类库.
MFC和QT是C++中常见的GUI框架,而WinForm和WPF是C#中常用的框架,不过我们一般很少叫WinForm框架,可能直接叫图形控件类库更多点.反正只是个称呼罢了,爱咋叫就咋叫.另外WinForm与WPF(即Windows Form与Windows Presentation Foundation,用于windows的上的桌面应用开发)都只是提供了一堆GUI类库,而MFC与QT除了一堆GUI类库外还提供了其他很多类.功能更强大.
GUI的重要性
GUI即graphical user interface(图形用户界面).可能很多人觉得整那些页面是个没啥技术含量的活.但实际上很多时候用户可不知道你后台代码咋写,也不管你咋写.他们看到的只有UI,觉得页面看着舒服,用起来性能不是太差,用个专业点的词说就是用户体验很好,那这就是个好软件产品.像苹果公司的产品这么受欢迎其中很重要的一个原因就是UI做的漂亮,让人觉得很酷.我们开发一个软件产品时,如果站在开发者的角度(站其他角度可能不一样)一个软件无非就是保存数据,处理数据,数据间一些逻辑操作,然后通过一个好友的UI界面与用户交互(当然有少数后台软件是不需要UI界面的).
我们知道各种设计模式是满天飞,五花八门,但知名度最高的是MVC模式(model , view,controller).就很好的体现了这一点,model + controller是数据处理那一块,而view就是UI界面.实际上QT,MFC,WinForm,WPF都相当于简化的MVC模式,由三层变成两层.model +controller没做区分,弄成一层了.而view这一层则是单独弄出来,UI与与数据的逻辑处理代码的分离使得条理清晰,便于理解与维护.而且更重要的是很多UI控件都是做好了的,你直接拖来用不行.
另外你可能可能听说过STL(standard template library),标准模板库相当于把数据结构及对数据的操作(算法)这些常用的东东都做好给你调用,相当于把数据结构和算法那些思想实现成通用的代码供你调用.
为啥把这四个框架放一起来说呢,因为四者之前有类似的地方.相同语言之间的框架有相似那是毫无疑问,但实际上不同语言之间的类库也有类似的地方了.C++中的MFC和C#中的WinForm有点类似,而C++中的QT与C#中的WPF又有点类似
MFC与WinForm
前面讲了这四个框架都是简化的两层的MVC模式.MFC中数据的逻辑处理自然是放后缀为h,cpp的这些文件中.而页面相关的那一堆东东放资源文件rc后缀的文件中.一般是一个project对应一个rc文件,但也可以多个project共用一个rc文件.当然在VS这开发环境中不会因为所有信息放rc文件中就所有页面控件堆一起了.在Resource View可以看到一个个分开的Dialog,每个Dialog就是一个页面,里面装着button等一些控件.当然资源文件还可以放其他资源的比如String Table,Bitmap之类的.如果你查看rc文件里的code,都是一堆begin
和end包起来的乱七八糟的东东.内容自然是控件的一些属性.code语法跟c++标准语法没半毛钱关系.也不知道是按啥语法组织的.
分开了UI层,如果那些处理数据逻辑的代码要与UI交互就靠资源ID去关联.比如很多类可以共用一个Dialog页面,当然了很多时候我们一般是一个class对应一个dialog的.MFC中UI页面与后台代码交互起来很不方便.比如要让某个控件(button,combobox之类的)与某个变量对应起来还得在DoDataExchange那函数里面写点代码关联起来.如果要点button要对应啥操作还得通过begin_message_map这样的宏来关联下.把某个控件送出的消息与一个函数对应起来的.当然了因为所有控件都继承自CWnd这类,所以也可以通过这类的一些函数去直接操作控件,比如GetDlgItem这样的函数,传资源ID做参数就行.
WinForm中也遗留了MFC一些思想,比如还有类似资源文件的东东,像Resources.resx文件,里面一般是放图片信息,然后Setting.settings就类似MFC里的string table.只不过这些功能在C#中用的很少.那些页面控件也不再是放资源文件中.WinForm中一切皆使用面向对象,数据逻辑处理代码与UI代码都是在同一个类中,只不过C#有分部类的概念,就是说同一个类的代码可以分开在几个文件中.假如有窗口类FormArwen,则数据逻辑代码放在FormArwen.cs文件中,UI代码放FormArwen.Designer.cs文件中.只不过这两个文件中类的定义都要写在partial
class FormArwen 其中关键字partial是C#中独有的关键字,用来表示分部类,一个类可以在多个文件中定义.这里的UI代码也完全是标准的C#代码,不像MFC资源文件缺乏可读性.而且你完全可以把UI代码拷贝到数据逻辑代码中,放一起也完全没问题.
窗口中每一个控件都有一个name,相当于mfc中的资源ID吧,然后你在代码中调用控件时直接用这个名字就行,就相当于一个变量名字.所以代码与UI交互起来非常方便,另外MFC中的消息机制在这里被封装成了事件(event),你选中任意一个控件然后在它的propterties 的event页面中选择任意一个事件点击下就会自动生成一个类,你往类中直接写要处理的事件代码就行.这实际上就是把win32 API中复杂的消息机制简化为一个event,用户用起来很方便,也不用管背后的复杂逻辑.MFC虽然对消息机制做了些封装,但封装的还不够好.
所以WinForm相对MFC而言,UI代码与数据逻辑处理代码交互更简单,更条理清晰,易于理解.背后一些复杂的细节都封装了不用用户管了.而且UI控件是功能更强大,看起来更漂亮啊.
同为C++的GUI框架,QT与MFC不那么相似,那种逻辑反而更接近C#的wpf框架一点.首先不是所有UI相关代码都像MFC一样整到一个rc文件,而是一个UI页面有对应一个后缀为ui的的xml文件.而数据逻辑处理代码是放h,cpp文件中.而且这三个谁的名字都相同. 而如果要与控件交互也跟wpf一样方便,每个控件有个objectName,相当于MFC的资源ID号,然后调用控件时直接用这个名字就行,当然前面要加个指向自身所在类的指针.比如有类Arwen,有button名为btn,则一般是先Arwen*
然后ui-&btn就行.实际上跟wpf中用this.btn一样,只不过wpf中this前缀是可以省略的.
另外QT里面也没有MFC中的消息处理概念,而是封装成一个叫signal / slot的机制.这跟C#中的WinForm事件(event)非常类似,例如你右击QT中的一个按钮,然后右击go to slot选择一种signal,就相当于C#里面的各种类型的事件,当然signal的各类要少点.然后slot就是事件对应的处理函数.
WPF也是一个UI页面对应一个文件,后缀为xaml的文件,xaml全称是eXtensible Application Markup Language我们可以把它看成一种特殊的xml文件.而QT里面的ui文件就是标准的xml文件了啊.然后其他UI无关的代码就放xaml.cs文件中.
应该说从符合我们思维习惯的角度来说WinForm是最容易理解的,UI页面对应的代码完全是标准C#代码. 而MFC页面对应的rc文件,QT页面对应的xml文件,WPF页面对应的xaml文件都不是标准的C++或C#代码.不太符合我们的思维习惯.
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：429740次
积分：7002
积分：7002
排名：第1110名
原创：271篇
评论：72条
(2)(2)(4)(1)(3)(1)(4)(2)(3)(14)(7)(5)(12)(43)(14)(12)(4)(24)(35)(23)(1)(1)(13)(5)(1)(1)(4)(30)(3)(1)&& 查看话题
【转帖】Qt vs MFC（Qt和MFC的战争）
关于Qt与MFC的话题，首选法国人Pascal Audoux所写的Impressions on MFC vs Qt Programming。当然，原文是法语，后由Philippe Fremy整理并翻译成英语。
其他站点获取以下URL地址链接到其他站点，小木虫不对链接的有效性、合法性和安全性负责，请自己决定点击查看，如果发现有问题，请及时向版主反馈。
再后来，Qtony Lliu又把它译成中文，就是下面这样了（其中错别字不少）。
/site/qtonyliu/impressionsonmfcvsqt
----------------------------------------
曾经使用过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的文档设计的相当优秀。你可以到上面一睹芳容。
Qt 的文档完备且详细的覆盖了Qt的方方面面，竟然仅有18M。每一个类和方法都被详尽描述，巨细靡遗，举例充实。通过Trolltech公司提供的链接或者是Qt Assistant工具，可以方便的从一个类或者方法跳转到其他的类。文档还包含了一个初学者教程和一些典型应用的例子。同时还提供了FAQ和邮件列表，方便通过Internet或者用户群来查阅。如果你购买了授权，在一天之内你将会得到Trolltech公司的技术支持。
实际上，Qt优秀的帮助文档使得寻求外部帮助的机会大大减少。Tolltech公司的一个宗旨是：有如此优秀的Qt产品以及其帮助文档，技术支持是多余的。
使用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编辑器不可能改变所有的属性，一些属性可以改变，另一些属性则不可能改变。(译者Qtony Lliu注：下面还有两条陈述MFC缺点的实例，但我感觉这些已经够说明问题了，暂时删节不译) 。
老汉按：下面是中文版中略去的关于资源缺点的英文版：
# The resource editor has limited features. For example, it is not possible to ajust everything with the dialog editor: some properties can be changed and other not. For toolbars, you are forced to use an image that contains the images of all the buttons. To set the application name, you must put certain strings in the string table, but you must know that every field is separated by '\n'. The order and the signification of every field is neither obvious nor easy to find.
# Resources are mapped to #defined numbers in the file "Resource.h" (a number < 32768). This creates problem when deleting or renaming resources. It is also a nightmare when many DLL use resource.h files with the same resources name but different numbers (typical case of a framework with DLL components).
# When using a DLL with its own resources, but which uses other DLL, there are many chances that the program mixes the resources of the program and the DLLs (even with #define to the same values). You must then reserve exclusive ranges for the resources, but it is not always possible as you don't necessary have control on any DLL.
然而，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压根就没有“升级整个系统”这个概念。
转自：http://phil.freehackers.org/kde/qt-vs-mfc.html
Impressions on MFC vs Qt Programming
Written by Pascal Audoux
Translated and improved by Philippe Fremy
After putting this article on the web, it has received the following critics :
& & * It is not very well written
& & * MFC problems are not very well described
& & * There is no code examples
& & * Qt is praised all over the article, so the article is biased
& & * The author does not show some deep knowledge of MFC and states false things
& & * The author does not compare Qt with .NET
I would like to respond: it is very hard and very time consuming to write an article. It is even more time consuming to write a good article with backed-up facts, code examples, comparisons, ... If I had such a good article, I probably would have published it on a more professional source, but not simply on my website.
I recognised these critics to be valid to some extent. This article was written to provide a slight overview of MFC programming but it reflects more all the problem we have faced when programming with MFC than a pure Qt/MFC comparison.
However, I still think that the material presented thereafter is valuable. I havn't found any comparison of MFC and Qt programming sofar. So please read on the only one.
The critics are online here: comments on MFS vs Qt. Drop me a mail if you want to add something.
Philippe Fremy
Introduction
I have been programming in both Qt and MFC. I would like to share with you my experience of the differences between using the two toolkits.
I am not a professional writer. So this article certainly is not as slick and clean as something you would find in a professional website or magazine. This is just my experience, that I share with you, in my own words. English is not my native language, so my constructs are probably a bit strange and there are mistakes. Please mail them to me, so that I can fix them.
This article does not pretend to be objective. It is just a report of my personal experience. I do not address every good and bad point of Qt or MFC. The fact that I knew Qt programming before starting MFC programming might alter my objectiveness.
This article is written from a pragmatic point of view: My boss gives me the specification of the applications he wants and I develop them. I have developed some with Qt, and some other with MFC.
The Microsoft Foundation Class (MFC) is a graphical toolkit for the windows operating system. It is a more or less object oriented wrapper of the win32 API, which causes the API to be sometimes C, sometimes C++, and usually an awful mix.
Qt is a graphical C++ toolkit started around 94 by Trolltech (). It runs on Windows (any version), Mac OS X, any Unix and on embedded devices such as the Sharp Zaurus. Qt is clearly and cleanly object oriented.
Document/View model
MFC programming requires the use of Document/View model and templates. It is almost impossible not to use them. However, templates have a fixed structure and it is very difficult to use them for something that was not planned by the template conceptor. Try for example to split an area and display two views on two different documents. Impossible. Another problem is that often, the template creates the view but it is not possible to access it. Everything must be done by the document and this can sometimes create problems.
Qt doesn't force any design model. You can use document/view without any problem, if you think it is appropriate. But you can go without it.
Pseudo Object Design vs Good Object
The fundamental difference between Qt and MFC is their design.
MFC is a kind of object wrapper allowing access to the windows API, which is written in C. This is not a good object oriented design. In many places, you must supply a C struct with 15 members but only one relevant to your case, or you must call functions with obsolete parameters.
And there are nasty tricks, without any consistency. For example, if you create a graphical object, it is not created until the Create() methods has been called. For dialogs, you must wait for OnInitDialog(), for views, you wait for OnInitialUpdate(), ... So if you create an object manually and call its methods, your program crashes.
Let's take the example of a dialog containing a CEdit control. You can not use the method GetWindowText() on this field if you are not inside the DoModal() method. It will fail miserably. Why isn't it possible to fetch the text of a control when the control is not in a certain state ? MFC is full of these nasty tricks. And it is hard to debug.
Qt is the opposite. The architecture is a good object oriented one and was obviously intelligently designed. The result is a toolkit very consistent regarding naming, inheritance, classes organisation and methods. Methods argument are the one you want to supply, no more. They always come in the same order for different classes. And the return value is logical. Everything is at the same time powerful and simple. Once you have used one of their classes, you can use many of them because they all work the same.
With Qt, to get an Edit control, you create your QLineEdit control with new, like any normal C++ class. You can immediately and forever access all its methods, whether it is shown or not. There is simply no trick, it works in the simplest way you could imagine.
Message loop
MFC is an event driven framework. To perform anything, you must react on certain messages. There are thousand messages sent by Windows to the program. Unfortunately, it is thus not easy to know which one to use, what information they contain, when they are exactly emitted, ... Some are redundant, some are not emitted, some are not documented. The documentation is not very good on this topic. It is difficult to know which objects emits what, when, which object receives or does not receive it and what action is taken. Some features available through messages could perfectely be available through direct calls. This message stuff doesn't help debugging or code review.
Qt is based upon a powerful callback mechanism based on signal emission and reception inside slots. This system is the core communication mechanism between objects. It can passes any number of arguments within the signal. It is very powerful. You connect directly your relevant signals to your slots so you know what is going on. The number of signals emitted by a class is usually small (4 or 5) and is very well documented. You feel much more in control of what is going on. This signal/slot mechanism resemble the Java listener approach, except that it is more lightweight and versatile.
Interface Creation
MFC does not handle layout in windows: this creates problems when one wants a window with a variable size. You must reposition your controls by hand on resize requests (This explains why many windows dialog are not resizable). The problem gets bigger with applications that must be translated, because many languages express things with longer words or sentences. You must rearrange your windows for every language.
Visual Studio's resource editor is very limited: you can place controls at fixed positions and that's it. A few properties can be adjusted and the class wizard allow to create variables and methods easily. However, it is worth noticing that it would be very tedious to create these manually: the message loop, the DDX, the IMPLEMENT_DYNCREATE are far too complicated.
With Qt, everything can be coded manually because it is simple: to get a button, you just write:
button = new QPushButton( "button text ", MyParentWidget);
If you want a method action() to be executed when the button is clicked, you write:
connect( button, SIGNAL( clicked() ), SLOT( action() ) );
Qt has a powerful layout mechanism which is so simple that you waste time when you do not use it.
Qt provides a graphical tool, Qt Designer, to help building the interface. You can adjust any properties of the controls you use. You don't put them at fixed places, it uses layout to organise things nicely. You can connect signal and slots with this tool, so it does more than simple interface design. The tool generates code that you can actually read and understand. Because the generated code is in a separate file, you can regenerate your interface as many times as you want, while coding at the same time.
Qt designer lets you do things that are not possible in MFC, like creating a listview with pre-filled fields, or using a tab control with different views on each tab.
(continue...) Documenteation - Help
Documentation is an important consideration when one wants to use a rich graphical toolkit. Visual's documentation, MSDN (for which you must pay separately) is huge, on 10 CDROM. It features many articles, that cover many tasks. However, it gives the feeling that it documents poor design choices and misfeatures, rather than current useful feature. The cross-linking is also very poor. It is difficult to go from a class to its parent or child class, or to related classes. Methods are presented without their signature. It is difficult to access inherited methods of a class. Another problem is that if look for a keyword, you'll get help on this keyword on VC++, Visual Basic, Visual J++, InterDev, even if you filter your results.
Qt's documentation is excellent. The best is to look by yourself:
It is complete and copious in the sense that it covers every Qt area, but fits in 18 Mbytes. Every class and methods is properly documented with plenty of details and examples. It is easy to navigate from classes and methods to other classes, using either the html version or the tool provided by Trolltech (Qt Assistant). The documentation comes with a tutorial and example of typical usage. There is also a FAQ and a public mailing list, accessible via a newsgroup or searchable web interface. If you have a license, you can ask the support which responds usually within one day.
The fact that Qt is well thought out helps a lot to reduce the need for external help. One of the stated goal of Trolltech is "The product and the documentation should be so good that no support is needed".
With MFC, to get unicode display, you must compile and link with specific options (and change the entry point of the executable). The you must add _T around every strings that you use in your program. You must change all your 'char' to TCHAR. Every string manipulation function (strcpy, strdup, strcat, ...) is replaced with other functions with a different name. And the most annoying is that a program compiled with unicode support won't work with a DLL compiled without unicode support. This is very problematic when you develop with external DLL, on which you have no control.
With Qt, strings are handled in a class QString that is natively unicode. No compilation/link requirements, no code alteration, just QString. The Qt code is natively unicode and there is no problem.
The QString class itself is very powerful so you use it everywhere, even when you don't care about unicode. This makes transition to unicode very easy. QString provides conversion functions to char * or UTF8 if required.
Technically, the big difference comes from the design of the MFC class CString, to be compared with the QString. CString is basically a char * with a few methods. The advantage is that everywhere where you need char *, you can use CString member. It looks good at first glance, but this has big drawbacks, specifically because you can modify directly the char * of the CString without updating the class. This is also a problem when converting to Unicode.
QString, on the contrary, stores internally a unicode version of the string, and provides a char * only when required. The whole Qt api requires QString for text arguments, so you very seldom use char *. The QString has also some additional facilities, like automatic sharing (or lazy copy) of the content of the string. The result is a very powerful class that you want to use everywhere. This is a typical example of a good design on the Qt side and a C hack wrapped in C++ on the MFC side.
Internationalisation
It is possible to internationalise a MFC program. Just put every string in a string table and use LoadString( IDENTIFIER ) everywhere in your code. Then, you must transform the resources into a DLL, translate the strings of the string table (using visual) into the desired language, translate the graphical resources (because their text can not be put into the string table) and ask the program to use this DLL. This is so complex that you probably can not defer it to a translator alone, he must be assisted. You will also have problems because in MFC, controls have a fixed position that depends on the non translated text. Longer translated strings will overlap. When you change some strings or add new strings, you must ensure manually that the translation has been updated.
With Qt, you just put your strings inside the tr() function . This is very lightweight when developing. You can change the reference strings directly in your code. A special program, Qt Linguist, will extract all the strings to be translated and display them with a friendly interface. The interface allow easy translation, with facilities such as use of a dictionnary, display of the context of the string, proper unicode display, shortcuts conflicts detection, detection of new untranslated strings, detection of modified strings. This program can be used by a translator with no development knowledge. The editor is available under GPL so you can modify it. The translated file is in XML, so it can even be easily reused in a different context. Adding a new translation to an application is a matter of producing a new file with Qt linguist.
Resources problem
With MFC, a part of the development process depends on "resources". You need them for many cases. This has consequences:
& & * It is almost impossible to develop with another tool than Visual Studio
& & * The resource editor has limited features. For example, it is not possible to ajust everything with the dialog editor: some properties can be changed and other not. For toolbars, you are forced to use an image that contains the images of all the buttons. To set the application name, you must put certain strings in the string table, but you must know that every field is separated by '\n'. The order and the signification of every field is neither obvious nor easy to find.
& & * Resources are mapped to #defined numbers in the file "Resource.h" (a number < 32768). This creates problem when deleting or renaming resources. It is also a nightmare when many DLL use resource.h files with the same resources name but different numbers (typical case of a framework with DLL components).
& & * When using a DLL with its own resources, but which uses other DLL, there are many chances that the program mixes the resources of the program and the DLLs (even with #define to the same values). You must then reserve exclusive ranges for the resources, but it is not always possible as you don't necessary have control on any DLL.
With Qt, there is no concept of resources, which solves all the mentionned problems. Qt provides a small script to include images into your code. For interface creation, three is Qt Designer that generates readable code.
Once you have bought Visual Studio, you get MFC SDK for free.
Qt is free in its Unix version (available under GPL) for Free Software. A non commercial version is available on Windows. But for commercial close source development, you must pay a Qt license. The license is for one platform (Unix, MacOs or Windows), per developer. It must be bought once forever for every developer and a one year support is included. There is no runtime distribution fee. The price is quite high for a small company: 1550 $ (there are discount for more than one license). Note that the cost is less than half a month of a developer. If you compare your development cost with MFC and Qt, Qt will make you earn far more than half a month in time of development and feature completeness. The investment is worth it.
Distribution
To distribute your MFC application, you could rely on MFC being present on Windows. But this is not very safe. Under the same name, MFC42.dll, you can get three versions of the same library. You usually have to check that the user has the correct version of MFC42.dll, and else upgrade it. Upgrading MFC alters the behavious of many applications. This is not something I am comfortable with. What if the customer PC stops working after installing my program ?
Qt names its DLL explicitely (qt-mt303.dll) so there is no risk of altering the behaviour of an application depending on, let's say qt-203.dll, when installing qt-mt303.dll . There is also no "I update your whole system" issue.
Other advantages of Qt
Qt is not only a concurrent of MFC. It is a full toolkit, with many features available in a simpler way than in MFC, and many that simply have no equivalent in MFC:
& & * Controls: Qt is a graphical toolkit, so provides a rich set of graphical controls: labels, combo box, toggle buttons, ... Some of them are very sophisticated, like the listview which allow to have multi column list view with icons and toggle buttons.
& & * XML: Qt provides classes to manipulate XML documents (using Sax2 or Dom). The tool is simple, powerful, complete and bug free.
& & * Regular Expressions: Qt provides full support for perl-compatible regular expression. This goes far beyound the simple '?' and '*' meta-characters. Regular Expressions are a very powerful tool, to parse documents, to grep patterns inside documents, to build filters, to define masks for edit controls.
& & * Multi-platform: Qt 3 is multi-platform. It works on Windows (any of them), Unix (any of them), MacOs X and embedded platforms. You just have to recompile your code to get it working on a different platform. Except for the compiler adjustments (or limitations), you don't have to touch your code.
& & * Template classes: Qt provides useful classes to handle lists, files, dictionnaries, strings, threads, ... All of them are very pow more than the STL and the MFC equivalents.
& & * Memory management: Qt has many facilities that makes memory management a no-brainer. Qt objects are automatically destroyed when their parent is destroyed. Many classes have an implicit sharing mechanism that relieves you from the pain of managing destruction and copy of these objects.
& & * Network API: Qt features classes to help programming with Network programming: socket, dns, ftp, http, ...
& & * Database API: Qt features classes for seamless database integration : Data aware wigets, database connection, SQL queries, ...
& & * OpenGL API: Qt provides classes for seamless integration with OpenGL (3D accelearted) libraries.
& & * Canvas: Qt provides classes optimised for handling quickly moving 2d objects, usually known as sprites.
& & * Styles: It is possible to fully customize the rendering of all the Qt controls. That way, Qt emulates the style of all the available toolkits: Motif, MFC, NextStep, ...
What about Codejock ?
The many drawbacks of MFC have left room for companies to sell MFC wrappers, which help to actually build applications easely. We have been using the CodeJock library. How does CodeJock + MFC compares to Qt ?
& & * CodeJock is a wrapper around MFC which is a wrapper around the windows API. Adding more wrappers to hide problems is usually not a good solution. All the cited problems still exist (resources, templates for doc/view, messages, unicode, internationalisation, ...)
& & * The classes provided by CodeJock allow easier use of MFC controles (simpler methods or more methods, added features). It it then possible for example to create a multi-tab view while it is _Mission Impossible_ with MFC. However, the library is very limited, providing only a few more classes than MFC, not a full set. We are closer to the set of patches than to a wrapper.
& & * The quality of the library is poor. Many bugs are left, new are added. During the first 6 month of 2002, there was 3 releases (1.9.2.1, 1.9.2.2, 1.9.3.0), every of them correcting more than fifty bugs, including major ones. The library is actually neither stable nor tested. This is not a professional quality tool. Users are alpha testers. Also note that the API changes between releases, and you must sometime alter your own code to adapt the new versions. This is a hint of the poor design.
& & * Reading the code (unfortunately unavoidable for codejock, given certain strange behaviours) reveals tons of horrors: methods with more than 500 lines, with some redundant code and plenty of return in the middle of nowhere, very few comments and many many hacks. Many classes members are declared public where they should indeed be protected and so on.
& & * Documentation is sparse, or void in certain cases (the method is present in the documentation, with no explanation of anything). Documenting doesn't look like a priority given its absence of progress in the last releases.
& & * There are no features present in CodeJock that you can not find in Qt. Except for the hexadecimal editor, which unfortunately is buggy as hell and that you can easily do in Qt (examples already exist).
Qt's code quality is very good. The library is always stable and robust. During the last 6 years, the source and binary compatibility was broken only twice, to add major features. And only in once case (Qt1 to Qt2) would this break require substantial code alteration.
Conclusion
The conclusion drawn from our personal experience is obvious. Qt is far better than MFC. You'll produce better programs with less hassle.
Some people complained that this article is biased toward Qt and does not present any MFC advantage. This is simply our experience : we had tons of problems with MFC, and almost none with Qt. Programming with Qt was always simple, documented and efficient. If MFC has good points, we have not found them, apart from being delivered free with Visual Studio.
We are of course open to feedback: for suggestions, improvements, remarks and flames, mail us!
I would like to include quotes of people who have used both MFC and Qt. If you have done so, please drop me a mail.
Other material comparing Qt:
& & * From Gtk to PyQt, by Philippe Fremy: analyses the same program written in Gtk, Qt and PyQt.
& & * Qt vs Java whitepaper, by Mathias Kalle Dallheimer.
& & * Guillaume Laurent explains why Qt is better than gtkmm
& & * Gui Framework 楼主不用纠结了，未来是苹果object-C的天下。 Originally posted by wth386 at
楼主不用纠结了，未来是苹果object-C的天下。 老汉何时纠结过？
每天一颗红苹果。
削皮去掉残农药，
大大小小切瓣多。 楼主，敢问你是研究什么的呢？
透露一些你的研究课题，简介一下吧，小虫们对你都敬仰已久~~:like: Originally posted by sondwall at
楼主，敢问你是研究什么的呢？
透露一些你的研究课题，简介一下吧，小虫们对你都敬仰已久~~:like: 网易开国前大佬【1】，DNA绰号莫等闲
有称前辈有典范，还有知己天涯边
谷歌百度全搜遍，老汉涂鸦飞满天
指点江山缺长笔，化解迷津谆谆言
木虫襁褓幼儿园，老汉频访已经年
最高一帖五八回，访问已达四五千
挥金如土不胜数，扁豆花开诗满坛
旗帜鲜明呼保义，高唱江水绿如蓝
-------------------------------
南拳北腿源少林
爬冰卧雪四体勤
N年苟延象牙塔
远渡重洋次等人
物化开路算能量
分析作眼观谱峰
合成乃是家常菜
无机晶体算应用
曾学Fortran玩到死【2】，
调试C语言摸秃顶。
Java到处去调试，
Perl站内忙运行。
Sybyl死啃SGI，
其实Linux也能赢。
加拿大出了个MOE，
Accelrys混大名。
体系小了没意思，
分子大了还难成。
QM/MM双双上，
依天哪能缺屠龙？
药物设计钱难瞢，
材料纳米却好碰。
随便用个能带论，
凑上数据来表征。
开源自由思想好，
可惜中国贡献轻。
拿来主义未百年，
抄袭剽窃已成风。
老汉年迈脑还灵，
尚能饭否死硬撑。
岂愿如此衰败体，
再捆官僚系统绳？
一台电脑能上网，
两指频敲字成行。
三顿素餐吃半饱，
四世同堂我据中。
---------------------------------
专业英语定要专
百篇文献鸭来填
翻译不必写下来
磕磕巴巴说两遍
遇见老外头冒汗
眼球开始往上翻
The The The The The没完
所有词汇全扯淡
如此这般费力气
不如先过听说关
咿呀学语最有效
吃喝拉撒都要沾
骂人千次无重复
语法不如语气鲜
语流语速和语调
韩乔意识半边天
下笔千言有文采
专业词汇如喷泉
希腊拉丁小点缀
欧美典故段前添
老外读来好亲切
四海之内有人缘
何日再建巴别塔
上帝奈何我痴颠
----------------------------
老汉非圣非仙，写诗表意浅见
六字五言七言，篇篇各有重点
有些随意跟进，其他自创新谈
或曰此非打油？好似数来宝玩
可知诗圣杜甫，还有居易乐天
通俗易懂为上，时事少用深典
国学并非故纸，短句含义凝练
客问或有软件？除非能者编纂
----------------------------
诗词歌赋四翩翩，唯独打油不算仙。
木虫论坛高朋坐，人间又到腊月天。
交流灌水或休闲，转载共享谈情感。
呼金换银刷百篇，想来虚度又一年。
飞骑难得妃子笑，咧嘴漏牙须狼烟。
倚老卖老耍笔墨，泣泪点点滴键盘。
时求文章时求典，转眼库存箱底现。
转炒骂顶绝招尽，支持鼓励何其难！
有人毕业有考研，进门出门走频繁。
新人可知旧人苦，血气方刚是少年。
身经百战虫披甲，谁知腹背伤难痊。
不可不戒不住手，网络现实难两全。
散文随笔需布局，不如打油省谋篇。
浓缩精华少敲键，可惜费脑难入眠。
夜半惆怅百千转，搜肠刮肚又一篇。
我的故事原创版，夜半两点交论坛。
不可不戒【3】本性偏，烧杀掠抢都占边
最大恶极乃好色，斗酒单刀法无天
浮生普渡心思苦，苦海无涯回头岸
剃发更衣仪表换，怎知内心何盘算
chevan【4】来自神生地，自由灌水欣欣然
潇潇暮雨【5】心天真，悄声提醒在耳边
可可西里【6】血浪漫，看完电视好茫然
物化妹妹【7】还在线，戒与不戒常呢喃
【1】网易（北京）社区
【2】到死=DOS，微软公司早期的单用户操作系统
【3】-【7】小木虫的虫友 LZ威武！:D Originally posted by nebulaly at
LZ威武！:D 威武算不上
不屈乃醇钢
关公实威武
弱兔马称王
& && && && &\\
& && && && & \\_
& && && & .---(')
& && &&&o( )_-\_ 别的都不用比
MFC只能用MS开发工具编译
这一条就够了 Originally posted by yalefield at
网易开国前大佬【1】，DNA绰号莫等闲
有称前辈有典范，还有知己天涯边
谷歌百度全搜遍，老汉涂鸦飞满天
指点江山缺长笔，化解迷津谆谆言
木虫襁褓幼儿园，老汉频访已经年
最高一帖五八回，访问已达四五千 ... =================
佩服，佩服~~~
化学全通，计算机软件+网络还能玩转，阅历又是如此的丰富，文采奕奕，深受启发，太牛了~~~ ddddddddddddddddd 个人觉得QT最大的优势还是跨平台，跨了X11，Mac和Win32，而且是二进制原生代码的（这一点相比落寞的java和现在炒得火热的.net确实优势太大）。
关键还是看应用的领域，如果要搞嵌入式图形界面的开发，那肯定非QT莫属了。
虽说新出的VS2010确实加强了MFC，但是编译的速度实在是让人崩溃。不过话说回来，两者都是基于C++的，只要真正掌握了其中一个，学习并善用另一个是非常非常容易的事情。 开源社区里貌似支持gtk+的人要多些 Originally posted by dedream at
开源社区里貌似支持gtk+的人要多些 谢谢回复。 GTK+3.0发布了，Qt又落后一年半载了，郁闷。而且Nokia这家伙不知道搞什么八卦，Qt社区现在唉声一片啊。 Originally posted by holmescn at
GTK+3.0发布了，Qt又落后一年半载了，郁闷。而且Nokia这家伙不知道搞什么八卦，Qt社区现在唉声一片啊。 Nokia不是正忙着啃微软的小腿肚子吗？ Originally posted by yalefield at
Nokia不是正忙着啃微软的小腿肚子吗？ 是阿，原来Nokia计划Qt作为Symbian，MeeGo的开发基础。现在Symbian不玩了，MeeGo甩给Intel了。Qt只能在嵌入和KDE上玩玩了。在Win下还是不太流行。加上GTK+的围剿。比较郁郁阿。 不错。学习了
var cpro_id = 'u1216994';
欢迎监督和反馈：本帖内容由
提供，小木虫仅提供交流平台，不对该内容负责。欢迎协助我们监督管理，共同维护互联网健康，如果您对该内容有异议，请立即发邮件到
联系通知管理员，也可以通过QQ周知，我们的QQ号为：8835100
我们保证在1个工作日内给予处理和答复，谢谢您的监督。
小木虫，学术科研第一站，为中国学术科研研究提供免费动力
广告投放请联系QQ： &
违规贴举报删除请联系邮箱： 或者 QQ:8835100
Copyright &
eMuch.net, All Rights Reserved. 小木虫 版权所有