Slashdot Mirror
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").
And not portable. Remember, it is becoming more practical to take off the blinders and support other operating systems. Writing a new application to support both UNIX and Windows, for example, not only results in a better application architecture (abstracted for portability) but also distributes risk (so what if either Microsoft or Apple or Linux falls by the wayside; I'm covered).
So, to fight a troll with a troll:
Why use MFC...when Qt provides better risk mitigation and has been industry proven.
Healthcare article at Kuro5hin
Perhaps the most useful of all would be a comprehensive somparison of all the various toolkits/libraries.
Everything in the Universe sucks: It's the law!
Qt is far better than MFC. You'll produce better programs with less hassle.
Very true. Literally within an hour or two, by following TrollTech's tutorial, a person can write and understand working GUI applications. One of Qt's strengths (and a tribute to its design) is how its learning curve is really quite low.
Healthcare article at Kuro5hin
I've been doing lots of Qt, GTK and Java programming, a few months ago I needed to start hacking on a MFC project. I tell you, never ever again. I'm now having a cronic headace, thanks alot MS. And what is it with those API's on Windows, do they have to typedef _everything_ for every different occasions, I'm sure I encountered 20 different typedef s for "unsigned int" just browsing through some MSDN pages. Not to mention the joy of unwinding a structure so you can get to business. Theres a structuer with a structure, member, with a member,with... And they each have members of type unsigned int, WORD, p_WORD, uint32. If somone know how to make apis and code even more unreadable I'm sure there is an open job somewhere near Redmond.
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.
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.
Zapman
Ummm... no. Qt may or may not report errors via C++'s exception mechanism, I don't know. But insinuating that exceptions are the *only* way to report errors encountered during a ctor is patently false. For a counter-example, one need look no further than the standard IOStream library:
// look ma, no try block!
#include <iostream>
#include <fstream>
#include <cstdlib>
int main() {
std::ifstream file("file.txt");
if(!file) {
std::cerr << "file.txt could not be opened for reading.\n";
return EXIT_FAILURE;
}
return 0;
}
It's always a long day... 86400 doesn't fit into a short.
That is one thing i have to disagree with the article. MSDN is quite good. And if you are using MFC, then you are using VC++. That means help is usually just an F1 click away.
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...
Black holes are where God divided by zero
Beaten... why? I think it's fun :-}
You're right on both counts. See this Usenet post for a little more detail.
It's always a long day... 86400 doesn't fit into a short.
I don't think there are many Windows programmers using MFC for new development. A comparison of Qt and .NET would be more relevant.
However, MFC isn't that bad. If you're developing a Windows application in C++, and you're forced into using MS only technology cause your boss won't pay the $1000+ per developer license for QT, and your choices are between using MFC and the base Win32 API, then MFC is the way to go. Granted, the Document / View Architecture is uh... well it's *odd*, but once you get the hang of it you can whip out a reasonably good GUI quickly.
MFC does do some nice things for you, mainly serialization and treating controls as objects, and the Message Maps are a vast improvement over the 10 page switch statements for Message Handling in Win32..
However, since MFC is "dead", I'd rather see a comparision between C# and Windows Forms vs. C++ and QT.. (and a lot of this I posted on Microsoft's own news groups.. hehehehe)
Seriously, If you want to see something that's godawful, look at C# and Windows Forms.
The below is from a post I submitted to Microsoft's own news groups.. to date, I have not gotten any kind of response from Microsoft. A couple of "Wait for Borland C++ Builder.NET" responses.. but nothing from Microsoft. Since MFC is "dead" and .NET is the "way" for Microsoft now, it makes sense to post this..
Especially if you have an option between QT and .NET... PICK QT FOR THE LOVE OF GOD.
While trying to develop a dockable tool window (much like the ones found in Visual Studio.NET) I've done a lot of research and had a lot of grief. Out of the box, you can't create a dockable window.
No one seems to know of any royalty free, open source solutions, and the .NET Magic library doesn't count. Look closely at the source and
you'll find that there's an awful lot of Win32 API calls being made
via PInvoke, which, per Petzold on page 237 of "Programming Windows
with C#", is "no longer writing managed code, and certainly not
platform-independent code."
So for the .NET Magic library users, what's the point of even
bothering to use C# and Winforms if all you're using it for is to wrap
Win32 API calls? Why not just use C++ compiled as a Win32 app and get
the performance increase and greater toolset? I know that making it a
dockable window is just a window style, (FWS_something, too lazy to
look it up right now, which you would think would just be a property
of a Control type, since Control seems to Map 1 to 1 to a Window.)
Which brings me to the largest gripe I have about the .NET framework:
The Winforms really suck. The overly simple UI controls it exposes are
simply not acceptable in today's enviroment. First, I'll give
Microsoft credit: Visual Studio.NET's UI is absolutely stunning, and
the C# language has some nice features....
However, it is seemingly impossible to create any form of advanced UI unless you derive your own controls or use PInvoke to create GenericPane window classes. And according to Spy++, those nice dockable, resizable windows are of Window Class GenericPane. Seriously, take Docking toolbars for example - we've been able to do this in MFC for years, so using "pure" C# really seems like two steps back instead of the leap forward the PR machine would have you believe. For any kind of advanced UI are we really forced to pony up money for third party libraries or roll our own? (And again, for the goal of "pure" C#, using PInvoke doesn't count.)
What's really maddening is that there's so many other language / RAD toolkits that do this much better. C++ / MFC, C++ / QT (for cross platform), Java / Swing, to name a few.
Even the Menus aren't dockable / moveable. What's the point of using managed code if the only applications you can quickly produce look like crap?
(my apologies to Wired Magazine)
Tired: MFC
Wired: System.Windows.Forms
Anyone creating an app from scratch right now, or porting an app not written in MFC, should _not_ be even considering MFC. New MFC enhancements are usefull for maintaing the (large) base of MFC apps written in it over the last ?10? years. It's time is over though.
-Malakai
A Dragon Lives in my Garage
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:
.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.
It has been three years since the last major update to MFC and ATL. With all the press on Microsoft®
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.
If ::new fails then it will throw, sure. But the object is free to catch std::bad_alloc inside the ctor and transpose it onto some other error-reporting schema. Just because something *in* the ctor throws, doesn't mean that the ctor has to propogate the exception.
As far as ifstream is concerned, you can't tell *why* the file couldn't be opened because ifstream is abstracted that way. You could easily have some sort of "error state" (similar to badbit, eofbit, and failbit) which can be reported to the client only when the client asks for it. Simplest way I can think of to do that is with a get_last_error() member function that simply returns the error code of the last operation the object performed.
Sure, exceptions can be helpful in RAII, but they are by no means required by it. To assume so is not only incorrect, it diminishes C++'s lack of paradigm bias.
The only time I can think of when you're *forced* to propogate exceptions is when you have a polymorphic class whose base class's ctor throws. But then, you made a design decision to inherit from a class that throws.
It's always a long day... 86400 doesn't fit into a short.
Any subobject (base class or data member) that throws during construction will result in the object itself failing with an exception. You can wrap the c-tor's initialiser list in a function try-block if your compiler supports it, but that only allows you to change the type of exception thrown, not the fact that some exception is thrown. If you think about it, that's the only model that makes sense, and it's also very clean and tidy.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Yes, that's the only way the object model can make sense *if you're containing actual objects*. You can easily get around that by changing the contained object(s) to a contained pointer to object. Same goes for private inheritance: change it to a contained pointer to object. If all your after is interface inheritance w/o polymorphism, just use a contained pointer plus forwarding functions. Like I said before, the only time you're *forced* to propogate exceptions from a ctor is when a polymorphic base class's ctor throws.
It's always a long day... 86400 doesn't fit into a short.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I think what you're trying to say is that if you don't want to allow a constructor to fail, you can change your design so that you can trap the exception that would be thrown by a base class or data member under normal circumstances. That's not what you actually said, though.
Of course, whether you want to have a design that carefully works around a system that's there for your own good is another question. Most of the time I've seen designs that went out of their way to ignore exceptions in a system that used them, the design was broken. Two-stage construction with Create() and Destroy() methods is a Bad Thing(TM) under almost all circumstances, and is responsible for more programming bugs in C++ than almost anything else I've come across (apart from naff use of pointers and arrays when smart pointers and container classes were the right tools for the job, of course).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I assume from the rest of your post that you're advocating using .NET instead? Why on earth would any development team of sound mind do that?
MFC, OTOH, while kludgy and less than well-designed, has a developer base of zillions across the world who know how to work around its kludginess and get the job done. It is tried and tested, so at least you have a pretty good idea where the bugs are. There is a lot of truth to the old saying "Better the devil you know".
If I had a new development team starting on a Windoze app, MFC certainly wouldn't be my first choice of tool -- far from it -- but it would be waaaaay ahead of anything to do with .NET.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Would that be the same Don Box who wrote about how COM was wonderful for years, but now says it's crap and we should all use .NET?
You should be very careful when listening to two-faced Microsoft weenies, particularly when they're demonstrably wrong. MFC was used in writing Visual Studio itself for a long time (though never, AFAIK, in writing things like Office).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I agree, there's also ATL i think that's even worse!!! I found it far easier to write using straight windows API.
Fortunatly I wrote my own Windows wrapper before MFC came along.
MFC might look good in comparison to Visuial Studio which must be one of the worst Dev environments I've ever used, I'd never take a job where Visuial studio was a requirement.
thank God the internet isn't a human right.
borland has Just released Kylix 3with C++ and Object Pascal support in one product.
/. yet?
Don't know why this hasn't made it to
thank God the internet isn't a human right.
Microsofts help was ok when it was in plain help files It just got shit when monkey soft switched to HTML help forcing everyone to install IE.
thank God the internet isn't a human right.
Sort of, but not quite. It's not a *design* change, it's an *implementation* change. Big difference. My only exception (polymorphic base class ctor throws) is the only situation where avoiding a throw in the ctor would actually require a design change.
I think we're pretty much in agreement, though. Don't know why anyone would go through all that trouble just to avoid a try block anyway.
It's always a long day... 86400 doesn't fit into a short.
OK, fair point, your change is implementation rather than design. And yes, we agree; exceptions and try-blocks are there for a reason, and it's usually easier to use them as they were intended than to fight against them.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Do people really have to look any farther to figure out why today's software is so buggy? The more subtle "gotchas" in a language, the more subtle bugs in the resulting products.
I understand the lure of mastering reams of arcane trivia. In fields like medicine, this is valuable. But, when you have to do so just to use a man-made programming language because of how often things are not what they appear, it is a stinging indictment of the poor design of the language.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
1st download a trial copy of CBuilder or Delphi and give there IDE a go...
.....
...
Here's my top hates....to the point of frastration.
1: (this is trully evil) the MDI interface.
2: Dialogues have loads of tabs but arn't resizeable.
3: Options arn't natural, e.g. right click on a project and I get
4: (part of 3) Options are hidden all over the place.
5: MSDN HTML help is shit (not the use of HTML for help, but the way MS have used it)
Here's a few things in CBuilder Delphi (as an example) that are farrrr superior.
1: No evil MDI
2: Options are quite easy to find
3: Fully RAD
4: Code compleation is highly typed e.g.
int a =
only lists things that can return or be cast to an int.
5: The help is generally quite good.
6: The api for extending CBuilder/Delphi is great and easy to use (easier than Visual Studio).
thank God the internet isn't a human right.
The best exposition I've seen was a set of three articles on "Reference Counting" in Herb Sutter's Guru of the Week series. You can find articles 43-45 on his web site, and as he notes there, an updated version is available in one of his books. You could also search the history for the Usenet group comp.lang.c++.moderated, where GotW is posted, to see more discussion on the subject. You might also want to check out the most recent GotW (questions but no solutions on the web site, but check the newsgroup history) for a few thoughts on why string classes tend to have overbloated interfaces.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The main problem with QT is this thing called MOC, some kind of preprocessor you need to run. Then of course, there's the license fee for use in any commercial software. Other than that, there's just the use of Expose events in X11 making it slow and ugly.