Thread: Ok so MFC isn't dead.

But that's you. Thousands upon thousands find MFC a good tool because it hides away the complexity of the Win32 API.
As Bubba mentioned, I could probably make a dialog in MFC as fast as in C#. With Win32 API only, it would take me a year (OK not really, but you get the point).
It's not the tool of the devil. It's a great tool. But it may not be for those who hate overhead and want to mess with the basic, underlying structure.

So, out of curiosity, do you prefer assembly over C/C++ too?

Originally Posted by abachler

I like being close to the metal, the metal is GOD. Since MFC is far from the metal, it is far from GOD. While it is not quite the devil itself (that would be Visual Basic), it is certainly something that assists the devil is leading people away from the straight and narrow path, hence the appelation 'tool of the devil'.

You sound like you have issues bigger than MFC.

I agree with indigo.

Originally Posted by brewbuck

MFC? Does nobody write straight WinAPI anymore? For that matter does nobody program Windows in C anymore?

I wrote a C program using the Windows API for someone. They said they didn't have a language preference as to what I used, so I went for C. It was quite an experience.

I would actually say it was fun.

Most of the problems I have in MFC are not from MFC but from the Windows Common Controls. Some of them are broken in some manner and most of them feel rushed out the door. I think MS's design philosophy was: " eh they will subclass our controls anyways so who cares."

What's with having a CListBox that does not add a scrollbar for strings that stretch beyond the client rect?

What's with having a scrollbar in CListBox that does absolutely nothing. This is an admitted bug that has never been fixed.

And there are some annoying supposed 'by design' issues in MFC such as popup menu items not having their ON_COMMAND_UI handlers called. MS released code to remedy this but the core design seems flawed and should have never left w/o taking this issue into account.

Drag and drop is a pain too without OLE/ActiveX. It's like MS couldn't figure out whether to force the coder to use OLE, subclass the control (and thus not be able to use the resource editor on their control), or hack together some other message based method. The docs in the SDK are less than helpful in this area.

So I'm not saying MFC is perfect but it is a nice tool and does for the most part speed up GUI dev.

I'll admit that the WinAPI is messy, but hell it's easy to use. You'd have to be a moron not to work out how to use it, and you can create and implement things fairly quickly with resource templates.

Originally Posted by Thantos

I'm not sure that is true anymore. Compilers are capable of some insane optimizations that most programmers would miss if coding the assembly themselves.

I have generally found that while the compiler does a good job of optimizing, it cant optimize for every possible intended use, it has to generate code that is bulletproff no matter the intention fo the programmer. Having first hand knowledge fo the actual effect you wish teh code to have gives one the advantage when hand optimizing the code. I guess it just comes with experience really, as I said, ive been writing assembly for a very long time. I certainly woudlnt want to write an entire application in assembly, as it would be exhausting. On the other hand, I dont want MS takign away my favorite tool becasue its 'too hard' to implement it for x64. You dont use a scalpel to cut down a tree, but you dont use a chainsaw to do brain surgery either. A case in point is processing 2 vectors. The compiler does a crap job of generating the loop structure, where hand coded assembly using the LOOP instruction can speed things up significantly. Dont even get me started on the implementation of CopyMemory as apposed to REP MOVSD. The compiler isnt set up to make judgement calls, such as slowing the program by pushing a few registers to the stack in order to use a much faster method for a big task. The SSE intrinsics generally generate unaligned code for vectors whose alignment is unknown, whereas I can write seperate sections that decide at run time whether to use aligned or unaligned opcodes. Not to mention doing things like using integer registers like EAX to hold floating point values. Compilers are good, but they cant beat a good coder that knows the metal.

Originally Posted by abachler

I have generally found that while the compiler does a good job of optimizing, it cant optimize for every possible intended use, it has to generate code that is bulletproff no matter the intention fo the programmer. Having first hand knowledge fo the actual effect you wish teh code to have gives one the advantage when hand optimizing the code. I guess it just comes with experience really, as I said, ive been writing assembly for a very long time. I certainly woudlnt want to write an entire application in assembly, as it would be exhausting. On the other hand, I dont want MS takign away my favorite tool becasue its 'too hard' to implement it for x64. You dont use a scalpel to cut down a tree, but you dont use a chainsaw to do brain surgery either. A case in point is processing 2 vectors. The compiler does a crap job of generating the loop structure, where hand coded assembly using the LOOP instruction can speed things up significantly. Dont even get me started on the implementation of CopyMemory as apposed to REP MOVSD. The compiler isnt set up to make judgement calls, such as slowing the program by pushing a few registers to the stack in order to use a much faster method for a big task. The SSE intrinsics generally generate unaligned code for vectors whose alignment is unknown, whereas I can write seperate sections that decide at run time whether to use aligned or unaligned opcodes. Not to mention doing things like using integer registers like EAX to hold floating point values. Compilers are good, but they cant beat a good coder that knows the metal.

A long while ago, we held a programming contest to do a brute force activity as fast as possible - you choose the platform, you choose the langauge....etc - just do it as fast as possible. I entered and used inline ASM. I had all the optimisations set for the compiler, tried to use APIs to speed up the code, used a few inline tricks to tell the compiler to leave my ASM alone and not add extra code to it. I spent ages profiling the code, switching instructions, juggling registers and doing everything I could to get it to go faster. The end result was very quick and smoked most other entries, but another member of this board submitted an entry which was almost all standard C++ code (very cleverly done) and his speed was so close to mine that it was almost identical (his was 0.009ms slower). When you looked at the other entries, they were well behind the two of us.

Now maybe I'm not a "great" ASM coder (I dont profess to be) and maybe someone else could have done even better, but the point that I got from the exercise was that all that extra work trying to outdo the compiler was lhow yourargely a waste of time - if you know your tools and the language and how your system works, you dont need to rely on assembler.

There may be times when some knowledge of ASM is needed - working with hardware and it can help with debugging. But those occurances are getting more and more rare.

Ive been on these forums for quite a long time, not as long as people like Salem and nvoigt, but long enough to have heard and taken part in every "this-way-is-faster" or "this-way-is-better" posturing that there can be. Ultimately, I've come to the following conclusions -

1. Knowing all the tricks and dark arts isnt worth much in the majority of cases but can be nice to know
2. Knowing your language, tools and basic system is very important and will give you more than trying to figure out how to break or fool those things.

Also: http://www.icfpcontest.org/

One thing I like about MFC is that it 'asserts' on exceptions rather than crashes (as WIN32 does) allowing more chance to handle the error.

One thing I hate about MFC is that it 'asserts' at every opportunity. ie setting a CTime to less than 01/01/1970.