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

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.

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.

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