PDA

Click to See Complete Forum and Search --> : Win32 API vs. MFC


Sc0rp
Aug 23rd, 2001, 01:05 AM
Pretty self-explanatory I guess. :rolleyes:
Go ahead. :D

Wynd
Aug 23rd, 2001, 01:10 AM
API!

Vlatko
Aug 23rd, 2001, 05:05 AM
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
Aug 23rd, 2001, 06:19 AM
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
Aug 23rd, 2001, 07:03 AM
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
Aug 23rd, 2001, 10:08 AM
I vote for API, with my own SMALL static library (about 10K :D) 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
Aug 23rd, 2001, 11:39 AM
I also vote the API, since it's more "powerfull" and you get rid of those annoying VB like runtime files :)

denniswrenn
Aug 23rd, 2001, 11:49 AM
I voted for the API, but if I was going to make something big, I'd probably use Borland VCL rather than MFC...

Sc0rp
Aug 23rd, 2001, 02:00 PM
So it's API then. :) :D

Megatron
Aug 23rd, 2001, 02:01 PM
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
Aug 23rd, 2001, 02:02 PM
Probably because they didn't know how to write real programs and went for MFC and now they have to maintain it:p

Sc0rp
Aug 23rd, 2001, 02:09 PM
Hey Kitten, LOL. :p

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

parksie
Aug 23rd, 2001, 02:11 PM
I think all the ASSERT macros disappear when compiling in release mode.

Olly
Aug 23rd, 2001, 02:34 PM
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 ???:confused:
But i will learn mfc a bit later, already got a book for it which I (luckily) did not touch a lot yet.

sail3005
Aug 24th, 2001, 12:11 AM
I say API, but then again, everyone here scared me into not trying MFC. ;)

Wynd
Aug 24th, 2001, 12:56 AM
Heh, me too ;)

CornedBee
Aug 24th, 2001, 02:30 AM
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
Aug 24th, 2001, 06:35 AM
Even if the ASSERTs disappear I still figure that API has a bit less overhead than MFC. ;)

TadaTensai
Aug 26th, 2001, 07:41 AM
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
Aug 27th, 2001, 07:54 AM
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.