Qt vs MFC

Philippe Fremy writes: "I have just published and translated into English a comparison between Qt programming and MFC programming, which was written by Pascal Audoux (a fellow coworker). I am interested in feedback and would love to add quotes from developers that have used both toolkits." Here is the English version ("Qt vs MFC") as well as the French one ("Qt contre MFC").

Comments

Good conclusion, poor article

[uradu]

While I wholehartedly agree with the conclusion, I must say that the article is a mess and feels like it was written by a 16-year old. It's barely comparative, sticking to the format that feature X is messy in MFC and much easier in Qt, and here's an example of just how easy. He doesn't give any MFC code examples, mainly limiting himself to explaining the horrors of Unicode and resources. An objective reader could hardly take this for a serious comparison of the two frameworks.

Besides, it's really comparing apples and oranges. Anyone who's used the MFC at all knows that it's hardly OO. A much fairer comparison would be that of Qt to Borland's VCL. In many respects they're very, very similar, but it seems that the nod of more consistent OO design would go to the VCL. I base this mainly on the event-handling semantics of both toolkits. While Qt falls back to straight C (or possibly even a macro? shudder!) for connecting an event handler to a component, the VCL stays faithfully OO, implementing event handlers as method pointers (exposed as properties) on components.

Continuing the example used in the article, Qt reads:

connect( button, SIGNAL( clicked() ), SLOT( action() ) );

while the VCL would read:

button.OnClick = action;

Anyway, as I said, while I support the conclusion of the article, based on its lack of maturity I wouldn't use it to try to convert existing MFC programmers.

Advocacy, we never knew thee.

[Zapman]

This guy doesn't seem to understand much of what he's talking about.

The most glaring clue is this:

For example, to swap two variables, the author used the non commented following line:

a ^= b ^= a ^= b;

This is a cool hack which does not belong to a professional product.

If you don't recognize this, you probably need to go back to school. It's fast, and it doesn't require a temp variable.

Any time you look at low level libraries, you're going to see things like this. They NEED speed. They NEED low memory impact. These things are going to get called in tight loops with a million iterations. Look at QT's code, and you'll see the same thing.

Also telling is the fact that he has nothing positive to say about MFC. I've run across some VERY talented developers, and while I haven't heard them singing MFC's praises, they do have some nice things to say. Advocacy really needs to show balance. Acknowledging MFC's strong points is important.

When he's talking about an add on library called 'codejack', he mentions that tab views are impossible in MFC, yet codejack provides it. Apparently it is NOT impossible in MFC then. It probably isn't a prebuilt widget for the developer to use (which is unfortunate, I'll admit)

QT is a good library, I have no doubt. But please learn how to find good things in other libraries. It will only make your code better. It will only make your advocacy better.

Re:Advocacy, we never knew thee.

[swillden]

a ^= b ^= a ^= b;

If you don't recognize this, you probably need to go back to school. It's fast, and it doesn't require a temp variable.

Bull.

It's an overly clever hack that doesn't belong in a professional product. Why? Four reasons:

1. Speed: It is not fast. It's far slower than the typical:

   c=a;
   a=b;
   b=c;

   Don't believe me? Grab a compiler, compile to assembler and check it out.
2. Storage: It requires exactly the same amount of storage, since the temp will always be in a register anyway (and the same register is required to store the result of computing a^b). Again, if you don't believe me, compile both to assembler and check 'em out.
3. Correctness: The line as written is *wrong*. It may work with some compilers, but the C and C++ standards both say that the result of the line is *undefined*. Why? You can't apply multiple operations including assignments to the same variables without an intervening sequence point (which, usually, means a semi-colon). The following is correct, although still slower than using an explicit temp:

   a ^= b;
   b ^= a;
   a ^= b;

4. Clarity: It is not immediately intuitive to anyone. Anyone who has seen the "cool hack" somewhere else will probably recognize it, true, but the use of a temp, or, even better, the use of std::swap() are guaranteed to be understandable at a glance. And there is no real, educational reason why anyone *should* have seen this hack, since it's really not useful.

The "comparison" article is poor at best, but in this aspect it is 100% correct. XOR-swapping is a cool hack but has no redeeming values other than its coolness, and cleverness for its own sake has no place in professional code.

Development tools?

[allanj]

As others have mentioned, the article is really badly written. I cannot comment on the merits of Qt, since I've done practically nothing with it. But I've done my fair share of MFC, and it's quite ugly - I find it hard to believe that *anything* solving a comparable problem can be much worse.
But my main point is this: When dealing with stuff like MFC you need to factor in the quite helpful development tools that the Visual Studio suite consists of. I have yet to see something of that quality from anyone else (except possibly Borland), and so far I've found only KDevelop to be reasonably useful. The MFC library (I flatly refuse to call it an object model) is ugly, but to some extent this is ameliorated by the IDE. I *know* this is not the way it should be done, but it's there and it DOES help...

MFC is NOT replaced by Windows Form

[edyu]

I don't know why everyone is claiming MFC is no longer in the picture after .Net. It's like claiming Newspaper was dead after TV came out. Here is an excerpt from MSDN:

It has been three years since the last major update to MFC and ATL. With all the press on Microsoft® .NET, MFC and C++ developers may be feeling left out. But don't worry--with the upcoming release of Visual Studio .NET, not only do developers using Visual C++® get a brand new IDE with tight integration for server-side development and a much improved C++ compiler, MFC and ATL have also received significant new features. The clear message is that MFC continues to be a great framework for developing sophisticated, rich client applications for all Windows® platforms. In this article, we'll provide you with a survey of the new features that you can use in your MFC applications.

There's a new MFC DLL (MFC70.DLL) that is no longer backward binary-compatible with MFC42.DLL, but your source is still compatible (although message maps have been made more type-safe, so that may break some code).

MFC and ATL are much better integrated, and common classes such as CString are now shared between the two libraries.

Header files are synchronized with the latest Platform SDK, supporting UI features in Windows 2000 and Windows XP such as themes and manifest resources, Active Accessibility®, and new common dialog boxes.

Many new UI classes have been added, including support for using DHTML in dialog boxes and enhanced bitmap support with CImage.

New utility classes can be used in both MFC and ATL applications, such as regular expressions, performance counters support, and security.

Now there's support for consuming Web Services in MFC applications and writing Web Services and applications with ATL Server classes.

High-performance access to databases has never been easier using the new OLE DB attributes and classes.

STL has been updated.

A bit *too* nice about Qt

[Anonymous Brave Guy]

I can't help feeling that, whatever its position on MFC, the article was unjust in its uniform praise of Qt. Some of the container classes there (QMap?) appear to be somewhat inferior versions of the STL equivalents, in case the C++ library in use doesn't support the STL parts properly, but doesn't support all the template guff required to use them(?!) To their credit, they do at least try to support the standard interfaces so you can use their containers with standard algorithms, which is a definite improvement over MFC.

The article also seems to praise QString, which is yet another string class with a Big Bloated Interface(TM) (doh!) that thinks using only mutable strings is the way forward (double-doh!) and reference counting/copy-on-write of a mutable string is a Good Thing (double-plus-doh!). These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc. If they wanted an improvement, they should have provided an immutable string class with a suitable set of operations, and a string-building framework to go with it where it's genuinely the appropriate tool. Oh, and being in native Unicode isn't particularly clever. Why not just use std::wstring, anyway?

As for the graphics, sometimes I want to lay out my dialog controls in exactly the positions I decide to put them in. Dynamic generation can be a good thing, but don't mandate it, because sometimes it's simply wrong.

I also have quite a bit of experience of i18n, and I'm all-too-familiar with the pain of translations, etc. For those who don't know, l10n (the opposite to i18n, i.e., making your location-generic application work in a specific locale) is about 10% translation and 90% integration, fixing up all the dialogs, ensuring that your UI can cope with reordered sentences (hope you don't like the IOStreams approach; printf had it right years ago) and so forth. A simple tr() function is not the silver bullet here, contrary to what the article seems to suggest.

Don't get me wrong, I think Qt is a nice library, and much better than many of the alternatives. But some of the claims in the article are just downright false.

Re:A bit *too* nice about Qt

[Anonymous Brave Guy]

These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc.

In 3 years of development with Qt, I haven't met any of the problems you describe. Maybe I am not writing the right programs.

Maybe you've been lucky. Who knows? The fact remains that there are demonstrated problems that can occur when using COW strings in a multithreaded C++ system, and further, the advantages of using such a design are mostly illusory anyway. It seemed like a good idea at the time, but on reflection, it turned out not to be. (BTW, I have watched an application fall over for no good reason because its string library wasn't multithread-safe when it should have been, and I've watched the development team waste several man-days of time trying to find the bug in their code -- which wasn't.)

If they wanted an improvement, they should have provided an immutable string class with a suitable set of operations,

You mean a QConstString

I don't think so. I mean a full-fledged immutable string class that supports the usual look-up and combination operations without the mutating ones, and a clean interface to convert between such a class and a vanilla QString. AFAICS, that's a whole world away from QConstString.

You can [lay out dialog controls in exact positions] if you want, even with Qt Designer. But I don't see when you want to do that. Could you give an example ?

In simple cases, I agree, an automatic layout can be very helpful. OTOH, on a program I used to work on, extensive used was made of tabbed dialogs. The layouts of most of them were fixed across all of the tabs, so that similar controls didn't jump around irritatingly as you flipped from tab to tab. I don't know if Qt's automatic layout system would handle that, but certainly no other one I've ever seen does. Automatic layout is simply not the best answer to everything, which the article seemed to be suggesting.

A simple tr() function is not the silver bullet here, contrary to what the article seems to suggest.

Yes it is. gettext() had it right from years. This approach allow the developer not to worry too much about translation, allow the translator not to cope with compiling stuff and get automatic update, and allow the user to add new language without hassle and to switch easily from one language to another.

With all due respect, if you think a simple translation mechanism like that is all there is to i18n/l10n, I can't believe you've ever worked on a large-scale multi-lingual application. There are other locale-related formatting issues (date/time, currency, etc). There are languages where routine system calls don't work on some strings (try a toupper on the German word Strasse, and then try the same on the same word written with a Schaffes s, and then compare them for equality). In Japan, most machines speak MBCS, not Unicode, so you need an effective means of converting between them, preferably as soon as the MBCS enters your program and just before it leaves so you can at least use Unicode internally. Some languages read right-to-left, or top-to-bottom, or even more devious variations, and you have to adapt your UI to cope with this, particularly when laying out dialog boxes and such. It is not as simple as a tr() function. (I'm not saying Qt couldn't cope with many of these issues, just that the emphasis placed on the tr() function by the article is overstated.)