For those of you not yet convinced of the evils of the Microsoft Foundation Classes (MFC), Philippe Fremy presents the English version of an article by Pascal Audoux that pits MFC against Qt. "The [Qt] architecture is a good object-oriented one and was obviously intelligently designed. The result is a toolkit very consistent regarding naming, inheritance, class organisation and methods. Method arguments are the ones you want to supply, no more. They always come in the same order for different classes. And the return value is logical. Everything is powerful and simple at the same time." I also found this old comparison of Qt to Java (see this one too) rather interesting.

Comments

This was in the slashdot developers section a while ago, and most people agreed that the quality of the article is very poor. Although I don't think anybody disagreed with the conclusion that Qt is much better to develop with than MFC, there was also an agreement that the article was of little value. They don't even try to find any advantages to MFC at all, and some /. comments suggest that the author doesn't have all of his facts about MFC correct. Maybe the writing quality suffers a great deal in the translation, but basically, if you want to skip reading the article, here is a summary:

Qt's [feature X] is soooo great and implemented in a uber-intelligent way. MFC's [feature X] is implemented in a hairbrained fashion and is ridiculously hard to use (or alternatively, MFC doesn't have [feature X] so Qt is so leet!)

Of course if you do read the article the auther makes most of these points in a disclaimer that he is not a professional writer and English is his second language. He doesn't claim to be objective and simply referrs to his experience. Here is part of his closing which references the "not finding anything good" about MFC.

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

Then again I guess there are some people who will simply let /. do their thinking for them. If they say the article is of little value the question is to who? To you? It's not of value to me as I can't and wouldn't (if I could) use MFC on Linux. It might be of value to a shop using MFC.

This isn't a good defense for this article.
If the author isn't a professional writer and especially if he's not objective he shouldn't write a comparison article.

I did not let /. do my thinking, because I didn't even notice the posting there (only on freehackers.org). When I read the article it didn't seem to be a comparison at all, this was plain and simple Microsoft / MFC bashing.

One of the authors 'best' arguments is about MFC's document/view model. He claims you can't nearly program without it... Of course not! If you let all work do the AppWizard.... I've written quite a project using VC/MFC, without document/view (and no, it wasn't just a dialog application).
In fact, the document/view model comes in very handy some times. And btw., i'm not a Qt expert, but I think Qt doesn't even have something like that....

I'd say: If you want to write a comparison article between two products (even if you're biased towards one of them) do it fair. Explain where and WHY one feature is better than another....

Hear, Hear! While I know nothing of developing in either environment, from one who reads alot (especially technical publications), the article is very poorly written and is [typically] biased. This isn't an 'us' and 'them' issue, people.

Maybe the author of this article is wrong in some points (e.g. you can program MFC without using it's Document/View model), the overall summarision is right.

MFC has realy some bad drawbacks:
- The message routing of the windows messages is realy bad designed. Depending of what controls you use, which container control and what styles set, the messages get delivered through different mechanism. (E.g. the parent gets a child notifcation message, the control gets the message directly, and so on).
- Ever had some problems not recieving messages or some redraw problems? Try setting the right style combination. This can be tricky since the styles of the parent control matter also (E.g. building own property pages using a tabcontrol. It is much fun to embend other resource dialogs ...)
- As stated, the documentation is very poor.
- Derivation of controls is not good supported. You can of course derivate from e.g. a CEdit control and create your own CMyEdit. There you can also override some methods or catch messages to implement an own behavor. But if you use resources to create dialogs and want to use your own CMyEdit control instead the CEdit you have to detach the MFC-CEdit object from the Win32 API windows control and then attach your (own created CMyEdit instance) to the Win32 API windows control.
- Translation of MFC programs in a Qt like way is possible -- just create your own translation tools ... ;) The problem with the layout remains.

Some things got realy better with the "new" ATL library. But this library is more a toolkit then a framework, and does not feature such things like MDI-Frames or a MVC.

The real problem is not the MFC -- its the Win32 API. And .NET WinForms is therefor mostly also as bad ... (The wizzards/designer for WinForms are much better than MFC one, also WinForms supports dynamic layout just like Qt, but you can't effectivly derivide from a WinForms control and change it's behavor without playing with Win32 API WindowProc .... -- don't even think about being able to run this in mono ...)

cu,
Emmy
P.S.: English is also not my native language. So please forgive me for my wrong english ;)

WinForms supports dynamic layout just like Qt, but you can't effectivly derivide from a WinForms control and change it's behavor without playing with Win32 API WindowProc .... -- don't even think about being able to run this in mono ...)

Matthias Kalle Swing vs QT is really far from being objetive. One part that really bothered me is when he gives some code examples: whenever Java code takes more lines than C++/QT code for the same functionality, then QT is better because the code is "more intuitive", and when whenever C++/QT code takes more lines, then he explains C++/QT is better, because the code is "more flexible". Biased at its best.

Comparing C++ to Java, he also says that Java's big standard API is a problem, because it is hard to find things on it. I don't agree, since Java packaging is well done, and classes are, as in QT, consistently designed, finding something in it is not really hard. I *suspect* it might be easier to find something inside the JDK standard API, than having to look for it everywhere, when you dont find it in the QT API. (And I have to say that 95% of all I have ever needed *is* provided by the QT API.. Oh no!!! QT API is BIG, now I wont find anything...!!).

The only 2 reasons I have to prefer C++/QT over Java for GUI aplications are performance and "look and feel". Well, those are HUGE reasons :), but I find it silly to ignore the fact that some stuff as GC actually reduces development time. Kalle quotes some studies showing how for the same task, experienced C++ programmers took less time than experienced Java programmers. I take that study with a grain of salt. I wonder how "experienced" in java the java programmers were compared to the C++ programmers (given that this document is supposedly a bit old, and java is not too old)

I haven't read the paper, but I do agree that the Java API, at least that part of it that I've used, is very well done and well-documented. And worse comes to worse you have rt.jar and could look at the source. That comes in mighty handy.

Of course, now Java has tons of libraries (CORBA/RMI stuff and all that) that look mighty complicated, but they've never bothered me.

I've programmed in AWT before and found it fairly nice. Unfortunately, it looks like and performs like crap.

Well, one actual problem with Java API, though, is that you get all sort of old vs. new generation classes (I certainly understand why Sun did this, and if I was in place of their engineers, I'd likely do the same -- this is the disadvantage of something being a platform and not a library, in a way)... Take for instance AWT vs. Swing; or the Java1 style Streams vs. Java2-style Readers and Writers vs. Java 1.4 new I/O.. The same with containers, to smaller extent... And further, I am not sure whether they are really consistently designed -- for instance AWT is rather minimalistic, while Swing has a whole lot of complexity for the Model/View separation (which despite looking nice on paper, I haven't found all that much use for, although my GUI programming with Swing experience is rather minimal).

- not using awt is simple, when designing Swing-Applications
- NIO is not a replacement for readers/writers, but a special case for extremly I/O-Intensive applications (that is apps that need the java-equivalent of mmap-ed files (be it files on the harddisk or even access to the graphic cards memory).

The Model/View seperation in Swing is extreme, but once you got the hang of it you really find it much easier to write a new Model than to use the kind of workarounds you use when starting to write Swing-Apps (everyone does this, I've never seen anyone start writing Swing code who used custom Modells first).

As for look and feel, there are several great jar files which allow you to greatly
improve the look of java applications. Sun's "swing sightings" pages show
a lot of good looking swing apps.

As for performance, it could certainly be improved. On the other hand, with
java 1.4 it's not too terrible anymore. We're developing a complex mapping application
from scratch in java, mapping thousands of objects on the screen with huge reaster
backdrops, lots of panels to edit map entities. And it's all working quite
well as far as performance goes.

Another poster mentions java's collection classes. Once they added the new collections
api, the collection tools improved a lot. Now all that's missing is templated
collections.

I think comparing Qt to Microsoft ATL/WTL (which is a lot nicer than MFC), or comparing Qt to .NET would be much better.

MFC is old hat, having existed for many years, and while many people have invested a lot of coding time and money in it, even Microsoft has gradually moved away from it, starting with ATL/WTL, and culminating in .NET

How about a comparison of two C# APIs? Or why not all three? GTK# (I feel baised here and says *yuck*), GDI+ (I like it, it is easy to use and powerful, much better than MFC), and the newest addition QT#. All three wrap another API (GTK, GDI/Win32, QT) in some ways and all three uses the same programming language. This would make it easier to write the same software with three different graphical frontends, which would give you an ok chance to evalute them further than just discussion the APIs.

Also, don't forget that QT was written as a reaction to APIs such as Motif and Win32/MFC. While QT is not perfect it has the advantage of being written from scratch and having a huge giant's shoulder to stand on. This is progression, we like it, I am sure QT will feel like motif in 10-20 years and young whippersnappers (sp?) will pit future systems against each other and call the users of the "other" system morons;)

Sometimes I think, that making a decision is a kind of art. There are a couple of ways to do things, and you express yourself in choosing one. And as more you move forward inside your decision, it's hard for you, to take the other way. So I am loosing more and more mental flexibility and I'm loosing the ability to accept that other people make other decisions.

And by the way: I hate the QT especially the signal/slot stuff - that's my decision.

I have been programing for many years, always considered talented wherever
i worked. I used MFC for 8 years and produced good looking apps with it.
I also read nearly every book on it [ including buying multiple versions of the same book ] and studied its internals [ i almost knew by heart the Shepherd/Wingo internals book ].

I could tell you :
1] When i started to use Qt, in 2 [ TWO ] weeks i could do more with it and in significantly less time than MFC.
2] All the developers around me who had experince in MFC were shocked by how easier and more powerful Qt was.
3] The author of the comparison article knows what he is saying, the critic on MFC drawbacks are all valid [ i can even name some more, even nastier pitfalls]

The facts are :

1] whoever doubts the article has not used Qt [ maybe not even MFC ] to prove me wrong, i need to see 1 [ one ] developer who used both MFC and Qt and thinks MFC is better or more productive.

2] I believe strongly that MFC was designed by inexperienced developers who knew very little about object oriented design when they started [ and finished ] the library. The fact MFC gained market support was entirely due to MS and not to any technical merit. There is no doubt in my mind that the Qt developers are talented developers.

3] i also believe anyone who claims MFC is good OOP design or is powerful framework is an inexperienced programer.

Come on, has nobody here written MFC apps seriously yet? This article is so full of errors, misunderstandings and pure opinion that I can only assume it's an anti-MFC troll.

Writing an MFC app without the document/view architecture is trivial. Message passing and the signal/slot mechanism for programme flow control are equally valid, with only personal preference to choose between them, really. The same goes for the means of laying out UI; Having seen some of the monstrously bad interfaces produced in Java, Qt _and_ MFC I know that whether controls are fixed in place or located dynamically in a window you can still completely muck it up.

The comments about documentation are hilarious. MSDN is an excellent resource, comes on 3 CDs or 1 DVD (where did that "10 CDs" come from?,) is supplied free with the MS IDEs and is free online, anyway.

Sorry if this seems to be a flame but I don't intend it to be that way. I'd love to see a well-written and accurate comparison of MFC and Qt, but this article doesn't come close.

yes i have written tons, including taking part in one that could
very well be the largest MFC app.
it was a direct competitor to an MS product. They were smart,
they did not use MFC, we did.

>> Writing an MFC app without the document/view architecture is trivial.

o From the Book "Professional MFC with Visual C++5" by Mike Blaszczak
who was a lead developer in MS's MFC team. page 191 :

Title : Document View-When not to use :
"The Microsoft Foundation Classes are designed to address the issues
faced by most developers in most of their projects.
It therefore follows that the majority will find them useful, but may
not fit every situation perfectly.
Some of these situations require you to abandon the idea of using
the document / view aechitecture.....
In all candor, you may wish to avoid MFC completely for projects such
as these, restricting yourself to stock C++."

o In Qt to create a splitter with 2 panes you do like this :
splitter = new QSplitter(this);
leftWnd = new QLeftWndClass(splitter);
rightWnd = new QRightWndClass(splitter);

No big deal, all very logical. Now please show how you do these 3 lines
in MFC without doc/view.
You can not, you will fail miserably and this is guaranteed [ correct
me with code if you wish ].

Even after conceding to using doc/view for this there is also a trick
to get the right pane different than the left.

first you need to define the doc-frame-view template, using only one of
the view types [ even a bogus type will do ]

This template binds the doc-view-frame types in one template.
The frame will use the view class defined in this template to create
the view. If left as is this will create the left view only in the frame.
To create the splitter we fool the process by over-riding the
frame's OnCreateClient() and create whatever we wish.

So not only did we have to use the doc-view for such a simple thing.
We had to fool the view creation to bypass the view defined in the
doc template. If you think think is a mess, you are right. Yack !!!

o Even the most primtive UI framework should support scrolling windows.
Can MFC support a scrolling window ?
Ehhh No. You have a CScrollView so you have to use Doc/View.

Try using a using a CScrollView inside a CDialog and not CFrameWnd,
it will crash when you mouse click anywhere in it. It's mouse
activation event is handled in a very clever way : walk up to
the CFrameWnd parent and assign this view as the "active view" of
the doc-view-frame template. No CFrameWnd parent .. bye bye app.

Using a CScrollView inside a CFrameWnd without a doc template is
also non-trivial. Requires "MFC internal knowledge" :
In the first version of Prosise's MFC "Programming Windows with MFC"
book shows how like this :
pMyView->Create (NULL, NULL, WS_CHILD | WS_VISIBLE,
CRect (0, 0, 0, 0), this, AFX_IDW_PANE_FIRST, NULL);

the "knowledge" is in assigning AFX_IDW_PANE_FIRST child ID to the view.
This hack was not in his second version of the book.

o Also assume you have a simple view that goes into a splitter or into
a frame, assume you wish to do a very simple thing like add a header
label on top of the view [ like a label with a title of "Folders" on
top of a cTreeView ].
How do you do this in MFC ? the splitter needs a RUNTIME_CLASS of a
single thing that it fits, should we create a new view type that houses
the lablel and the cTreeView ? In this case all the doc-view messages go
to the wrapper view, how do we route the messages to the CTreeView ?

o Dialog Controls are also handled in a very ugly way. for example to
get text from an edit control we either use something like :

CEdit* pNameCtl = (CEdit*) GetDlgItem (IDC_NAME );
pNameCtl->GetWindowText (m_text);
We also have to be careful : the pNameCtl pointer returned is
valid only during the processing of the message and cannot
be saved and used later !

another way is add the following macro inside DoDataExchange()
DDX_Control(pDX,IDC_NAME,m_NameCtl );
though i have no problem using any number of macros, i find these
macros less elegant than simply using old style C SDK programming
the Charles Petzold way. and certainly ugly compared to the logical :
pNameCtl = new QEdit(this);

o The CFont class is a classical show of MS C++ knowledge, can you
imagine the CreateFont() functions takes 14 paramaters and none have
default values, you have to specify all of them like
OUT_CHARACTER_PRECIS, DEFAULT_QUALITY. are these C++ experts creating
us the library to use ?

>> Message passing and the signal/slot mechanism for programme flow
>> control are equally valid, with only personal preference to choose
>> between them, really

o not really, in Qt you can assign any object to receive messages from
any other object. you can have many recipients of the same message
event. You have total flexibilty.
In MFC in non doc/view, the control sends to its parent window,
in doc/view ...YACK forget about that.

>> The comments about documentation are hilarious. MSDN is an
>> excellent resource..

o true, MSDN is an excellent resource but the MFC docs is a very
small part of it and very badly done.

o As for saying the Qt should be compared to C#. Not really, .NET
is a new technology. Qt is a regular C++ framework the MFC developers
could have very well produced something like it back then.
As far as being unfair comparison, that is true, it is like comparing
a jet fighter to a biplane.

>> yes i have written tons, including taking part in one that could
>> very well be the largest MFC app.

Sorry, the article was such an unjustified anti-MFC diatribe I presumed
you had limited experience.

> >> Writing an MFC app without the document/view architecture is trivial.
>> From the Book "Professional MFC with Visual C++5" by Mike Blaszczak
>> who was a lead developer in MS's MFC team. page 191 :

Try a Dialogue box-based app, which doesn't have document-view.
Alternatively, create an SDI app and rip out the document-view part.
I've done it plenty of times, so I know it to be possible.

True, MFC isn't for everybody. I usually use ATL, because you end up
with much lighter applications.

>> In Qt to create a splitter with 2 panes you do like this :

That's hardly an MFC problem, is it? Why should MFC cater for every way
of writing a UI? Why not write your own class which creates a splitter?
This is hardly a fair point. I could say something like "you can't create
COM controls easily with Qt" and it would be an equally unfair comparison.

>> Even the most primtive UI framework should support scrolling windows.

Just how much code you have spoon-fed to you is indeed a matter for
philosophic debate.

>> Can MFC support a scrolling window ?
>> Ehhh No. You have a CScrollView so you have to use Doc/View.

I suppose a CScrollView isn't a scrolling window, then? :)

>> Try using a using a CScrollView inside a CDialog and not CFrameWnd,
>> it will crash when you mouse click anywhere in it.

Any fool can write broken code. Why put a CView-derived window where it isn't meant to go?
Scrolling dialogue templates would be no good thing IMHO and, if you want a text
area which scrolls, use a CEdit-derived window.

>> Using a CScrollView inside a CFrameWnd without a doc template is
>> also non-trivial.

It's true that, whereas MFC is designed to make easy jobs easier for people
new to Windows programming, some things are better done if you have
in-depth knowledge of the underlying system. I hope that, as an
experienced Qt programmer, you understand its architecture (along with the
underlying X-Windows system) inside-out.

>> Also assume you have a simple view that goes into a splitter or into
>> ...should we create a new view type

Why not? It _is_ a new type of view, after all.

>> In this case all the doc-view messages go to the wrapper view,
>> how do we route the messages to the CTreeView ?

Fortunately, MFC handles routing of unhandled messages down to the base class for you!

>> Dialog Controls are also handled in a very ugly way. ..
>> We also have to be careful : the pNameCtl pointer returned is

Congratulations, you've discovered what the scope of a variable means.

>> i find these macros less elegant than simply using old style C SDK programming
>> the Charles Petzold way.

Again, a matter of taste. I prefer to hit the Win32 API directly sometimes, but
MFC can make things so much easier.

BTW, haven't you discovered the "Member Variables" tab of the class view yet?

>> The CFont class is a classical show of MS C++ knowledge, can you
>> imagine the CreateFont() functions takes 14 paramaters and none have
>> default values, you have to specify all of them like
>> OUT_CHARACTER_PRECIS, DEFAULT_QUALITY. are these C++ experts creating
>> us the library to use ?

Of course, all API calls should come with built-in mind reading so that they can tell
exactly what you want! Microsoft's font engine is pretty powerful and has a lot of
knobs to tweak, if you want to. You don't have to use CreateFont if you don't
want to, though.

>> In MFC in non doc/view, the control sends to its parent window,
>> in doc/view ...YACK forget about that.

You pays your money, you takes your choice. Whichever way you know best will seem
to be the correct one. Don't flay MFC with your own opinion.

>> true, MSDN is an excellent resource but the MFC docs is a very
>> small part of it and very badly done.

>> That's hardly an MFC problem, is it? Why should MFC cater for every way
>> of writing a UI? Why not write your own class which creates a splitter?

>> Just how much code you have spoon-fed to you is indeed a matter for
>> philosophic debate.

i just gave 2 examples : scrolling window and splitter, i thought are basic
elements any simple ui framework should provide.
If you feel these were unfair to expect from a framework, no problem i'll type
some other examples later.
Note that MFC does provide those when using doc/view which was the original discussion.
Also the ugly code i mentioned for creating 2 different views for the splitter is
not my hack, it is found in any MFC reference or book that explains the splitter class.
This is "official" MFC code.

>> Any fool can write broken code. Why put a CView-derived window where it
>> isn't meant to go?

i was just trying to prove the point that the scrolling support in MFC cannot be
used outside the doc-view model, so we both agree here.

>> if you want a text area which scrolls, use a CEdit-derived window.

i meant a scroll area for a custom window you write [ one that you derive
from CScrollView or QScrollView ].

>> I hope that, as an experienced Qt programmer, you understand its architecture
>> (along with the underlying X-Windows system) inside-out.

my experience in Qt is not great, but in 2 weeks i was more capable with it that
my 8 years of MFC. I also know zero X-Windows, yet my Qt code ran flawlessly on
both Win32 and Linux.

>> Why not? It _is_ a new type of view, after all.
>> Fortunately, MFC handles routing of unhandled messages down to the base class for you!

you miss my point : this new view is just a wrapper that includes the label control and
the original CTreeView derived view [ the real view ], ie we have 2 views. The problem is
that MFC will treat the wrapper view to be the one associated with the document. So we have
to write code ourselves to route message from-to the wrapper to the real view.

>> Congratulations, you've discovered what the scope of a variable means.

this has nothing to do with variable scope, it has to do with an MFC screw up that the
(CWnd*) pointer returned from (CWnd*) GetDlgItem (); is valid only during a single
event handler. Storing this value into a global variable and using it in a latter
event will crash. The "wisdom" behind it is that these object pointers are put into
a temporarymfc CWnd-HWND hash map that gets cleaned peridically. Thank you MFC !

which i mentioned in my earlier message, i have no problem using these lovely macros and
exchange contexts, i just said that i feel regular C / SDK looks cleaner and certainly
Qt's logical :
m_NameCtl = new QLineEdit(this);
is cleaner.

>> Microsoft's font engine is pretty powerful and has a lot of knobs to tweak, if you want to.

i am not complaining about the Win32 font engine, it is excellent, it could have as many params
as it wants. My complaint is the MFC design of the CFont class requiring you yo specify all these
params and not making use of C++ feature of specifying default params, this is C++ 101.

i've used mfc a fair amount and qt a lot. i've also used atheos's framework code, done some heavy hacking on the jx framework and learnt gtk/gnome. this is in addition to designing my own oo app framework/guis a while back.

qt is the easiest and most powerful i've used.

jx is a very close second - well designed and useful. it uses plenty of the OO functionality C++ ;

atheos's gui framework is also rather nice. simple and lets you get the job done with the minimum of fuss.

gtk--/gnome-- arn't amazing - but lets face it they're wrappers, so they live upto basic expectations.

mfc is, quite simply, bollocks. it only barely passes itself off as an "object orientated" gui framework. some of it doesn't even work to spec (afaik - i specifically the serial port interface was shafted).

my personal big time gripe:

why the hell do the designers not use default parameters? they wouldn't take away functionality that's for sure. have they not heard of them? maybe m$ are in kahoot with the keyboard manufacturers and all those extra keystrokes will cause extra keyboards to be bought - who knows?

i guess they got the random 14 yo kid there on work experience who had a vague idea what classes were and how to translate from stucts{} and function(struct *, ...).

i just gotta say for the record, in my experience mfc sucks. big time. i haven't read the article, but assuming it says a similar thing, fair enough ;)

o One more MFC classic.
In SDK C programing, when dealing with painting code, care
is needed to cleanup and deselect GDI objects we selected in
the DC (device context) and restoring the DC back after we finish.
This was a common error that had nasty effects.

When i started to use MFC, i was certain the MFC classes will take
care of traking these resources and doing the needed cleanup.
Any KID who read the BASICS of C++ will realize the classes should take
of this.

unfortunately the MFC graphics classes : CDC, CPen..etc do nothing more than
the native handles HDC, HPEN they supposed to represent.
The code is exactly like using native C / SDK like :

This is in-excusable. specially incorrect cleanup was known as a common
programming error.
Surely the CDC class could have kept a flag of what was selected,
what is the old value to use when deselecting, and keep pointers from objects
such as CPen,CBrush,CBitamp to their CDC, so whoever goes out of scope the
cleanup shuould be automatic.

Yep, CPen and CBrush are thin wrappers around Create(Stock)Object and SelectObject. It would have been much nicer for CDC to keep track of what had been selected, then do a restore at the end. It would have made life easier. I'm glad if Trolltech were able to build on Microsoft's work and produce a simpler version, with the benefit of not having backward-compatability to think of.

Notes :
In Qt, you do not differentiate between the window C++ object and
underlying window you see on the screen [ which is the basics of C++
encapsulation ]. As far as the developer is concerned, instanciating
the object with new() takes care of everything.
To set window properties we use set and get functions. That is it.

In MFC, you have to differentiate between the C++ object and the physical
window. You also have to be careful when to set properties and be aware of
the stages of window creation :
- Some object properties are set when instanciating the C++ object.
- Some window properties need to be defined when calling CWnd::Create()
- Some window properties need to be defined just before the physical
window creation : such as in PreCreateWindow()
- Some window properties need to be defined just after the physical
window creation in OnCreate() such as setting the image icons for
the tree. They rely on the physical window having been created.

In my opinion, this is totaly un-acceptable
Also note the wide use of SDK types and constants such as CREATESTRUCT,
TVS_LINESATROOT, TVSIL_NORMAL.
Apart from platform portability [ which itself is a BIG thing ], Qt is cleaner,
flexible, and easy to understand.

Notes :
In Qt when you insert a node, you insert a C++ object of type QListViewItem
or a derivative of that type.
In many cases, we insert a type derived from QListViewItem, which contains
app specific data. For example if the tree represented a list of people,
the new QListViewItem derivative will include things like names, telephone,
addresses...etc.
In MFC there are no C++ objects involved, again we are using SDK style
handles HTREEITEM.
This makes a big difference as we will see later.

Notes:
In Qt when the tree selection changed, the C++ object of the new
node pNewItem is sent to the OnSelChange message handler.
As explained earlier, this object could be a derivative of QListViewItem
which contains app specific data [ like the telephone, address example given
earlier]. Since we have the selected object pointer, we can take necessary
action, such as displaying its data in a different pane.

In MFC when the tree selection changed, we get ( as expected ) nothing more
than the Win32 SDK structutes NMHDR,NM_TREEVIEW from which we get
pNMTreeView->action and pNMTreeView->itemNew.hItem which contains the
Win32 handle HTREEITEM.
As this handle is really meaningless to the app and means something only to
the OS, the developer typically builds a lookup table between the HTREEITEM
and the app specific C++ data associated with this item, this is typically done
while inserting the items in step 2 using a hash map like CMap.
During processing of selection changed, the map is used to loockup the C++ object
from the HTREEITEM.

Other advantages of sending C++ object node pointer instead of an OS handle is
we can easily use its functions such firstChild(),nextSibling(),temAbove(),childCount()
also delete the C++ object deletes the nodes..etc.

As a side note here :
There are also much more advanced Qt display customization features that
handle the overall application look and feel to a desired theme and style.
You can dynamically flip through them at run time instantaneously :
such themes include Win95, Motif, Solaris, XP, Apple Aqua ..etc
This is all the logic result of clean oop design.

The ability to switch the appearance is because of the use of style (which fortunately implemented as plugin). In addition, XP only works on Windows XP (the styles utilizes DLL which does XP theme interface) and Apple Aqua only available in Mac OS.

You wrote a lot of stuff, why you like the QT so much. Are you working for trolltech ?

I have programmed several years for windows 3.1 in C. And the C-Windows-Api has a lot of stuff, that xlib doesn't have. Menubars, Scrollbars, Dialogs, MDI etc. The MFC is a wrapper, that a person who understands the C-API can easily understand, because the way of thinking doesn't change very much, it's just more comfortable. Additionaly MS has done a lot of work, to keep the MFC backward compatible. The samples of my MFC 1.0 book are still working.

I haven't analysed QT for windows, but it seems to me, that the wrapper is much more higher than MFC. QT also have another message system, so as a windows progammer, I have to care about C++-messages, Windows-messages, Automation-messages and QT-message (the signal/slot stuff) -at least during debugging. Personally, I think that the QT message system is a message-system to much.

I have no motivation to learn another abstract model for the windows-api. Every C++ Windows programm knows the MFC. There are no communication problems. There are sites like codeproject.com and codeguru.com with lots of MFC sample code (It's like CPAN for perl).

And at least, there is the same framework-killer, similar to OWL: If MS introduces another feature (what they do regulary), I have to wait until trolltech introduces that stuff into qt, if they ever do. If I use the MFC, the sample code is delivered by Microsoft, or I can get it from a third-party-developer.

If I write a windows-Only application, I must be brain-dead, if I use QT.

> And the C-Windows-Api has a lot of stuff, that xlib doesn't have.
Because they're basically different. Xlib only provides basic interface, extend it using whatever toolkit you want/evangelize/like/hate.

> The MFC is a wrapper, that a person who understands the C-API can
> easily understand, because the way of thinking doesn't
> change very much, it's just more comfortable.
Fine, if it suits for you. For me, the problem is simple: because it's really closed to the C API (like Maged said, even doesn't provide default value to assist the programmer), what's the point of making it a C++ wrapper ?

> QT also have another message system, so as a windows progammer, I have to
> care about C++-messages, Windows-messages, Automation-messages and
> QT-message (the signal/slot stuff)
If you use a Qt-only program, why care about Windows-messages ? They're already taken care inside Qt. And what's C messages are you referring, too ?
FYI, use ActiveQt (check Trolltech website) and COM-enabled your application easily.

> Every C++ Windows programm(er) knows the MFC
Such a claim. What about people that don't use MSVC but go with say Borland C++Builder instead ? That VCL abstraction in C++Builder is of course no MFC at all.

> If MS introduces another feature (what they do regulary),
> I have to wait until trolltech introduces that stuff into qt,
> if they ever do
So you use every little bit of MFC's features ? Well, the 80/20 should also apply here. Most of time, only the-really-important stuff is being used, which can be done cleanly using Qt. If you want to push the limit of MFC, then go ahead.And I'd also like to know such features (GUI related one) which already in MFC but are not yet implemented in Qt.

Note that I'd like to say that it's OK if MFC is your choice, because it serves your purposes very well, but if you try to convice people not to use Qt because "no motivation to learn another abstract model", I simply disagree. Learning Qt is IMHO worth the time, but nobody forces you to do it.

>> Every C++ Windows programm(er) knows the MFC
>Such a claim. What about people that don't use MSVC but go with say Borland C++Builder instead ? That VCL abstraction in C++Builder is of course no MFC at all.

Just google for sites, that handle with VCL and than look for MFC sites. If you know a site as big as codeproject.com or codeguru.com, tell me. Curently I don't know anyone, who is using VCL now. They have switched to Java or MFC.

>So you use every little bit of MFC's features ? Well, the 80/20 should also apply here.
If Microsoft introduces a new eye catcher, every application, that doesn't use this eye catcher looks old. This has nothing to do with 80/20 - (by the way, about 80/20: http://www.joelonsoftware.com/articles/fog0000000020.html )

But I don't like signal/slot. May be I'm too old for signal/slot, but I prefer fixed message-method mapping E.g. It's possible, that "show" is emitted and "display" is called and later this is re-mapped to "show" again, and I have to search, who has reconnect that slot. I prefer that there is a fixed place, where such kind of mapping takes place in plain C++.

I think, to convice people not to use QT, this is not the right place to do it :-) I just think, that using QT on a windows-only project, might not be a good decision. Hating signal/slot is a complete personal thing, but having so much support for MFC, is a fact.

The key argument for MFC are these:
- It's supported by Microsoft, even if there is .NET and even it's a little bit obsolete (I think, I can trust on Microsoft's future more that on Trolltech).
- There is a lot of addtional free support on the web and from third-party-developers (not free, but worth the money).
- During hard debugging sessions, I can use my old C-WIN32-API knowledge easily.
+ I prefer a fixed message-method mapping.

I would have never guessed I'd live to see the day that someone would actually defend the MFC in such a selfless and ardent way as yourself. I'm afraid you've got more religion than even Microsoft themselves, judging by the twins facts that they themselves don't use the MFC internally for anything worthwhile, and that they're in the middle of a wholesale shift to a Qt-like framework.

Consider the MFC to be Microsoft's OOP learning phase, the missing link between SDK and C#. You can do some very revealing searches against the MSDN to discover Microsoft's gradual shift from "OOP is overrated" (back during the MSC7 days), through "ok, encapsulation is useful, but inheritance isn't" (COM days) and "what are templates good for anyway?" (obviously pre-ATL), up to today's .NET-mania. Reading all the .NET code samples promulgated by Microsoft shill FTP's (Fawcette Technical Publications) countless magazines, it seems Microsoft finally made their way through Gamma's Design Patterns. Interfaces, abstraction and delegation galore, an exhuberance for OOP never much seen since the early days of Smalltalk.

As you can see, even Microsoft isn't of your opinion that the MFC is a Good Thing. They've realized that bread-and-butter programmers don't care about the messy nuts-and-bolts, they just want to get a job done. Unfortunately, the MFC is all about the nuts-and-bolts, it downright forces you to mix levels of abstraction within your code. The shift to comprehensive frameworks is OOP's probably most lasting legacy. These frameworks represent a comparable increase in productivity to the shift from assembly to higher level languages. Sure, it's all still happening underneath, but for most tasks you don't have to care. A good framework hides most of the complexity but lets you drop down below if you have to, a trait similar to what made C so popular.

Take Borland's VCL, which lets you program all day long without even knowing what OS you're on. But if you do want to get at the handles and messages, they're right there for the taking. The MFC does no such hiding--in fact, I have no clue why it's even using classes at all, because it offers few of the benefits of OO and takes little advantage of it. Deriving from MFC classes saves very little work and still forces you to sprinkle macros all over the place. Breaking an MFC app is as simple as forgetting to close a message map, resulting in the most bizzare and misleading errors.

It took an ex-Borlander for Microsoft to come up with a good framework. So far .NET looks like something an entrenched OO programmer could get to like. It's both powerful and simple, so don't be suprised if Microsoft start writing a lot of their future apps in C# themselves. This time around they might actually do as they say, unlike in the MFC days.

If Microsoft doesn't use MFC internally, why do applications like word, explorer, internet explorer, etc. are depending on it ?

Concerning the base class library like MFC,QT or VCL, I believe, that better service is more important than pure OOP. If you need an specific control, you can write it on your own (e.g. 2 weeks) or you can reuse a ready one (2 hours).
I prefer the 2 hours solution and this means MFC ( No I don't repeat the websites here again).

That a new class library is more OOP than existing ones is not a surprise. If I had to decide between C# and Java, I prefer Java, because there I'm a little bit more sure, that stuff is working.
As I heard, some parts of .NET are currently rewritten from scratch.

I'm afraid I have to disappoint you on all three accounts. Using both Dependency Walker and Process Explorer you can see that none of the mentioned apps use MFC*.DLL in any shape or form. They're all straight API apps (directly or using ATL/WTL). Actually, I spoke too soon; Process Explorer does show WINWORD.EXE as using MFC42.DLL, but I believe it's one of the Office Integration components that I'm using (FileNET) that is using the DLL, not Word itself.

> I believe, that better service is more important than pure OOP

Absolutely, no sane person would be doing OOP just for the sake of it, and user-friendly encapsulation and hiding of complex APIs is what (well-done) OO frameworks excel at.

> If you need an specific control, you can write it on your own
> (e.g. 2 weeks) or you can reuse a ready one (2 hours).

Definitely.

> I prefer the 2 hours solution and this means MFC

That's where you're dead wrong. There are much more drop-in components and code available for the VCL and Qt than for MFC or (God forbit) OCX. In fact, most of the MFC code I've seen is of the cookie-cutter recipe variety to scratch a very specific itch (i.e. most of CodeCentral), but relatively few ready-made generally useful components. Check out the third-party components available for Borland's Delphi, both commercial and free, they blow away anything available for MFC or VB. This is particularly astonishing in view of the developer ratios. What absolutely flabberghasts me is the lack of a great number of freely available OCX controls, especially after VB introduced the ability to easily create them. I attribute this to the fact that even though there are huge hordes of VB "developers", the vast majority of them are very superficial programmers and have little or no knowledge of COM and OLE controls. Still, after VB5 and VB6 came out, a lot of people had expected that a wealth of OLE controls would soon flood the scene and dwarf the number of Delphi components. I still expect that this might happen with .NET, since it includes a nice language-independent controls model.

> As I heard, some parts of .NET are currently rewritten from scratch.

Most parts of .NET are written from scratch, including the class framework (with the possible exception of the VS IDE, which seems to be a continuation of InterDev).

Incidentally, many people have written their own class wrappers around the Win32 API, even after MFC was released. Sure, not comprehensive frameworks but rather just wrappers for the components they needed. I still have a book on the shelf from the early 90s, Windows++, that shows how to implement your own OO wrapper around the Win32 API. Believe me, the end result looked nothing like the MFC, much more like Borland's OWL and VCL, or like Qt.

This one goes to you, the epxlorer and most of office doesn't depend on mfc42.dll (but Visual Studio 6.0 and Frontpage do :-). But I don't thing, that they use VCL or QT.

I can remember that I compared Visual C++ 1.0 and Turbo C++ V4.5. That time I realized, that I'm faster learning and using MFC than OWL. May be I'm a bad OOP skilled programmer in your eyes, but until now I haven't found a killer inside the MFC that really let me think about a switch (and I got my projects on time). Every problem could be solved with the support of the web and some colleagues. Also I'm prefering that MFC is not so flexible. That's make it easier, to maintain other people's code. Why change a system that works ?

Nevertheless the amount of components for delphi/VCL looks really impressive, so I asked a former Delphi user, why he doesn't use it anymore. He told me that Java has better support, better components and an increased productivity than delphi. After that he showed some really cool Java tools (refactoring, unit-test etc.). Believe me, Java has more from a killer than OWL/VCL/QT/.NET.

Never said they did. In fact, for most internal projects MS use plain SDK, the ATL, and the (very little known) WTL. I suspect the reason for that is that it gives them more flexibility in refactoring code later on than with using the MFC, even if it means more work up front (particularly with straight SDK). My point was only that even for Microsoft themselves the MFC isn't good enough for serious long-term projects.

> I asked a former Delphi user, why he doesn't use it anymore

That has a lot to do with the job market. Unfortunately most large companies stick to MS-only tools consequences be damned, much more for economic reasons (site licenses etc.) than for best-of-breed reasons.

> Believe me, Java has more from a killer than OWL/VCL/QT/.NET.

Java sucks precisely in the area Delphi (and Qt) excel at: GUIs. Show me someone who actually LIKES Swing apps and I show you a masochist. Java may be great for a lot of things, but the desktop it ain't.

One thing with Java is that I can use it to any platform for free; and I should pay a hard price to Visual Studio and Delphi. First point for a developer: the price.

QT is expected to work on most platforms, whereas in MFC you only work on Windows. Like you, I choose QT only if I make some multi-platforms program.

When you're wrong is to think that in Java we cannot make such powerful graphical interface. Have you heard of QTJava ? As for you, I hate Swing, and a port of Qt in Java represents for me the ultimate solution, as both Java and QT work in most platforms.

Final point: by isolating all specific-platform codes, you can easily port your software from an OS to another. QTJava suits well, and QT too.

I don't think there is such a lot of guys who use MFC and MFC only. In small applications, we don't need to reinvent the wheel. If you make a component in pure MFC, well congratulations, but porting it to another platform one day could cost you to rewrite it someday.

We must always think that Microsoft will one day fall, whereas some other OS will climb. And making solutions that can be easily ported to another platform is not a crazy thing.

To defend QT, I will simply say that this library has sufficient features to suit to commercial programs, even in Win32 platforms as it now integrates ActiveX support (IE, and so much components that the developers can use in another platforms... An oriented-objet ActiveX component to handle the System Tray, why not ?). I can access DataBases, make some Networking operations, create some powerful components and graphical interface; and most of it: if one day, the project must be ported to another platform for any reason, it will be very fast to port it... And in MFC ?

I know that you don't care about porting your applications, but think that as you cannot say the future, you don't know if someday, you should have to prot your applications.

Java is really good for almost all applications indeed. But when it comes to Desktop applications, C/C++/Delphi has its part. Being programming for various platforms, till day, I fond couple of +ves and couple of -ves in each of the varients discussed in this topic.

MFC:
1. MFC has only its use/maintainability till you have the Wizards of Visual Studio available. ;-). Just imagining a senario without the Wizards of the Visual Studio, there is just a little difference between MFC and Qt!!!. You (Programmer) has to do everything.
Yes. I do agree that there is a lot of documentation on MFC (Actually not MFC but the Windows API). (I had to look in the 5 DVD manual on the documentation for just finding out a small help!!!).

2. MFC is not available for other platforms!. Means if once a program is developed on Windows platform, The program always have to GLUE itself to Windows. No matter how many bugs it has!!!!. Where as Qt is available on many platforms.

3. MFC Look & Feel is good!. (Because everything looks like the same!). Somewhere I read in a UI design concepts document, that you need to imitate other Programs as far as possible, because the user of your program is an EDIOT!!!!. and doesnt accept changes. (And I find it true :-) ).

4. MFC programs indeed be ported to Other platforms. Using WIND/U code library which comes for a HUGE cost.

5. Windows Programs also can be executed thru WINE emulator. But being Slow!.

I also some time back wanted to port one of my MFC code to Linux! Bah... I found Nothing but Errors. MFC library just cant be ported!

So.
Use Qt: if you want portablility + look & feel
Use MFC: If you think that programs will never be ported to any other platform.