Win32 API vs. MFC

[Sc0rp]

Pretty self-explanatory I guess.
Go ahead.

[Wynd]

API!

[Vlatko]

API is definetly better, faster but there are things that are real hell to be done just with the API. In these cases MFC is a better choise. Anyway i vote for API.

[CornedBee]

MFC is far easier and faster to create, but once you get to some more complicated techniques, getting through to the API can be pain-in-the-ass (BTW can anybody eplain how subclassing in MFC works?)
I have voted for MFC, but I admit that API can sometimes be the better choice.
About speed, since mostly MFC apps are working apps written in C++, I don't think speed is all that much an issue. I still can't see any obvious delays.

[gfiorani]

I am fairly new to Win32 programming in C++, but from what I can see, it seems like MFC is similar to the VB runtime. I could be way off base here, but don't you have to include special libraries with your app if you use MFC? Anway, I vote API.

[parksie]

I vote for API, with my own SMALL static library (about 10K ) to make things easier.

Originally posted by CornedBee
MFC is far easier and faster to create, but once you get to some more complicated techniques, getting through to the API can be pain-in-the-ass (BTW can anybody eplain how subclassing in MFC works?)
I have voted for MFC, but I admit that API can sometimes be the better choice.
About speed, since mostly MFC apps are working apps written in C++, I don't think speed is all that much an issue. I still can't see any obvious delays.

CWnd::SubclassWindow I think.

[CyberCarsten]

I also vote the API, since it's more "powerfull" and you get rid of those annoying VB like runtime files

[denniswrenn]

I voted for the API, but if I was going to make something big, I'd probably use Borland VCL rather than MFC...

[Sc0rp]

So it's API then.

[Megatron]

I like API too, but I've heard many people say that when you work with C++ in real life, many compaines demand that you use MFC. Is this true? (I don't know because I've only used VB in the workplace).

[parksie]

Probably because they didn't know how to write real programs and went for MFC and now they have to maintain it

[Sc0rp]

Hey Kitten, LOL.

Anyway, I heard the MFC is full of asserts and slows down code drastically.

[parksie]

I think all the ASSERT macros disappear when compiling in release mode.

[Olly]

I think that the real point with this is the following:
when you already know a lot of the API and always have been programming with it then the smaller sized and easier looking mfc looks quite strange. You will think why you should learn such a quite different thing when you already know the API. Why learining the same thing twice? Also it's a big issue that the API programmers have worked up their asses for the API and then cheeky MS comes up with its foundation class libs and makes everything that you achieved in long and hard work bloody easy.
Sure you will then vote for the API. Beginners in my opinion shouldn't even think about starting with the mfc (as well as starting up with vb instead of c, as I did ), because you then get used to it and are too lazy to learn the far more difficult API stuff (and for me c++ from vb).
When you really get to need it or have to program something crucial for non windows platforms. Would you then like to rewrite all that crap then for API ???
But i will learn mfc a bit later, already got a book for it which I (luckily) did not touch a lot yet.

[sail3005]

I say API, but then again, everyone here scared me into not trying MFC.

[Wynd]

Heh, me too

[CornedBee]

The ASSERT macros DO disappear in release versions.
Parksie: I know the function SubclassWindow, I just have no idea how to use it. Do I have to derive a class from CWnd that will handle the messages? How do I use CallWindowProc? It's so damn complicated that I want to use the API, but I need access to the variables of my CView, so I came up with the idea to use a static member function of my CView-derived class as the new message handler for the control. Is this possible???
About which programs are MFC, there's an easy way to find out. Use the WindowFinder tool and search all the windows and child windows of a program. If there is a single window class named Afx:xxxx (where xxxx are some numbers), the application is guaranteed to be created using MFC.

All the buzzt
CornedBee

[Sc0rp]

Even if the ASSERTs disappear I still figure that API has a bit less overhead than MFC.

[TadaTensai]

API is DEFINATLY more fun.....

But it IS annoying....

And coming from the VB world, MFC can be good sometimes.....

::uses API 99% of the time::

[Jimbob42]

yeah api all the way
I had my programming style foistered on me by my lack of MSDN anyway, meaning the only thing I had was borland's win32.hlp. I suppose that's a good thing, judging by how crap everyone says MFC is.