MFC does introduce some overhead as compared to a raw Win32 application. And if your application does very little, then yes a 20% or more performance penalty can be seen. If your application does a lot then the overhead becomes negligible. This is assuming a competent MFC programmer. An incompetent MFC programmer can accidently introduce a whole lot of unnecessary overhead which may seem like it's MFC's fault, but is actually a problem with misusing MFC.

Quote:Original post by SiCrane
MFC does introduce some overhead as compared to a raw Win32 application.

But you know what the overhead is not any more, and likely less, than writing your own functionally equalvalent GUI framework. Also, MFC is faster than Qt for sure, and probably wxWidgets (why would wx be faster??). Contrary to popular belief, MFC does not even use virtual functions for its message mapping, so you don't even have the overhead of calling virtual functions for messages.

I've used MFC since VC 1.5 back in the early 90s. Sure we've had some rough spots. Maybe the docs could be a little better, perhaps CDockBar could be exposed, the tool bar could be more robust, but the bottom line is that once you become more familar with it, the frustration of using it will certainly go away. Make no mistake about it, you'll end up writing your own control bars, but the framework is already there to write them and get them to work... and its EASY to make them.

Admittedly, you've got to learn how subclassing and serialization work to really take advantage of it. Once you learn the internals you'll never want to switch.

MFC is an awsome toolkit and it doesn't get nearly the credit it deserves. I'm tired of pansy-ass programmers dissing it because "they don't get it". Well I tell them, "hey if you want to be hand held go use C#, and take the 50% to 80% performance hit on your UI."

Quote:Original post by DrEvil
Do you know offhand some examples of the overheads involved?

Take window creation. MFC creates a CBT hook with a state block that last the duration of the entire thread. It maintains quite a bit of information in the thread local storage, and when CWnd::CreateEx() is called, the address of the CWnd is placed in the TLS. Also stored is a per thread HWND to CWnd handle map.

Now when a message arrive directed at a MFC window, it goes from AfxWndProcBase() to AfxWndProc(), which then looks up the HWND from the window handle map. AfxWndProc() then calls AfxCallWndProc() which replaces the HWND with the CWnd *, which then calls CWnd::WindowProc(), which calls CWnd::OnWndMsg() when then takes the message, cracks it open, and forwards to call to the correct handler.

Quote:Original post by krum
But you know what the overhead is not any more, and likely less, than writing your own functionally equalvalent GUI framework.

I'm pretty sure I could write an equivalent GUI framework that didn't need to do a linear time lookup to connect HWND handles to class pointers that had a minimum of five function calls for every windows message recieved that didn't have a redundant RTTI implementation or require a per thread initialization function.

Or I could just use ATL instead.

Or I could realize that the speed of the GUI framework is irrelevant since if GUI actions are taking a signficant amount of time in your application, then it probably means that your application isn't doing very much.

Quote:Original post by SiCrane
I'm pretty sure I could write an equivalent GUI framework that didn't need to do a linear time lookup to connect HWND handles to class pointers

MFC does not do a linear lookup. It uses a hash table.

A hash table with open chaining that generates an absurdly large number of collisions when using HWND values as a key. Which degenerates into a linear search.

Quote:Original post by krum
MFC is an awsome toolkit and it doesn't get nearly the credit it deserves. I'm tired of pansy-ass programmers dissing it because "they don't get it". Well I tell them, "hey if you want to be hand held go use C#, and take the 50% to 80% performance hit on your UI."

Please tell me that was a joke...