Qt vs MFC（Qt和MFC的战争）

老汉按：
关于Qt与MFC的话题，首选法国人Pascal Audoux所写的Impressions on MFC vs Qt Programming。当然，原文是法语，后由Philippe Fremy整理并翻译成英语。

其他站点获取
以下URL地址链接到其他站点，小木虫不对链接的有效性、合法性和安全性负责，请自己决定点击查看，如果发现有问题，请及时向版主反馈。
http://phil.freehackers.org/kde/qt-vs-mfc.html

再后来，Qtony Lliu又把它译成中文，就是下面这样了（其中错别字不少）。
http://sites.google.com/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的文档设计的相当优秀。你可以到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编辑器不可能改变所有的属性，一些属性可以改变，另一些属性则不可能改变。(译者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压根就没有“升级整个系统”这个概念。

举报删除此信息

yalefield(站内联系TA)

转自：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 (www.trolltech.com). 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...)

yalefield(站内联系TA)

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: doc.trolltech.com
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".
Unicode
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 Qtapi 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.
Price
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 powerful and very handy; 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.
Links
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