MFC vs Qt

 Impressions on  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:

<a href="http://phil.freehackers.org/kde/qt-vs-mfc_comments.html" target="_blank">comments on MFS vs Qt</a>

. 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 (

<a href="http://www.trolltech.com/" target="_blank">www.trolltech.com</a>

). 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.

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:

<a href="http://doc.trolltech.com/" target="_blank">doc.trolltech.com</a>

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 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

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,

[email=phil%20at%20freehackers.org]mail us[/email]

!

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.

Programming