Win32 Vs MFC
Hi,
Which one is best to use? MFC or pure Win32 programming.
Which one gives the maximum control over the application we are creating (from MFC or Win32)?
Which is easy to use (MFC or Win32)?
I can survive anything ... even NUKES!!!
The Lion King
I'll leave this up as long as nobody starts a flamewar/pissing contest over their personal preference.
>Which one is best to use? MFC or pure Win32 programming.
Basically MFC IS the Win32 API. MFC is just a nice object oriented wrapper to go around Win32. There is no best, it all depends on what you are doing, and how much time you have.
>Which one gives the maximum control over the application we are creating (from MFC or Win32)?
If you are looking for absolute speed or control then Win32 would be the way to go. Remember, MFC is a wrapper , it just manages all the Win32 control stuff.
>Which is easy to use (MFC or Win32)?
If you are looking for easy and your application has more than just a simple window with a button MFC is probably best. The whole reason MFC exists is to provide a well structured interface for creating gui applications. Obviously with the ease of use, and shorter debugging time comes more code bloat from all the extra stuff in MFC that you don't use. The decision of which one to use is all up to you.
[edited by - Michalson on May 22, 2002 8:11:14 AM]
>Which one is best to use? MFC or pure Win32 programming.
Basically MFC IS the Win32 API. MFC is just a nice object oriented wrapper to go around Win32. There is no best, it all depends on what you are doing, and how much time you have.
>Which one gives the maximum control over the application we are creating (from MFC or Win32)?
If you are looking for absolute speed or control then Win32 would be the way to go. Remember, MFC is a wrapper , it just manages all the Win32 control stuff.
>Which is easy to use (MFC or Win32)?
If you are looking for easy and your application has more than just a simple window with a button MFC is probably best. The whole reason MFC exists is to provide a well structured interface for creating gui applications. Obviously with the ease of use, and shorter debugging time comes more code bloat from all the extra stuff in MFC that you don't use. The decision of which one to use is all up to you.
quote: Snippet from For Beginners FAQ
Q. OK. I read Start Here. I still don"t know which langauge/API I should learn. What do I do?
A. For starters you DO NOT post questions like this (which has been done to death) and expect to get any kind of advice that is going to sway you one way over the other. Would you go to your local Super Mall and ask on a loud speaker what type of person you should date? Second only to prOn there is no other waste of bandwidth than these types of threads. What ever you do, nothing good can come from ??? vs ??? threads. period.
[edited by - Michalson on May 22, 2002 8:11:14 AM]
MFC is basically just a wrapper around the win32 API that in addition adds a lot of advanced functionality.
The pros of MFC over win32 are:
* You need to write less code to do the same thing.
* You get a nice OO interface to Windows programming that makes things easier to understand.
* You some code given to you for many things - this is especially the case if you work with OLE components.
The cons of MFC are:
* If you use the Document/View architecture (which is not required) then the application usually gets slower - so the Doc/View archiecture is not good is speed is vital.
* The learning curve is more steep. I generally recommend learning old-fashioned win32 programming before you start with MFC since you otherwise will not have clue about what goes on. Do *NOT* just think that because you can use the Wizards with MVC++ that more easy get started since these produces a lot of code you most likely do not know.
* The exe''s get larger (due to the MFC library).
Used at its basics (i.e. without Doc/View) MFC is just a Object oriented wrapper about win32 that makes things easier without preventing anything.
Of books in MFC I recommended: Jeff prosise: Programming Windows with MFC.
I have yet to come by a really good win32 book.
The pros of MFC over win32 are:
* You need to write less code to do the same thing.
* You get a nice OO interface to Windows programming that makes things easier to understand.
* You some code given to you for many things - this is especially the case if you work with OLE components.
The cons of MFC are:
* If you use the Document/View architecture (which is not required) then the application usually gets slower - so the Doc/View archiecture is not good is speed is vital.
* The learning curve is more steep. I generally recommend learning old-fashioned win32 programming before you start with MFC since you otherwise will not have clue about what goes on. Do *NOT* just think that because you can use the Wizards with MVC++ that more easy get started since these produces a lot of code you most likely do not know.
* The exe''s get larger (due to the MFC library).
Used at its basics (i.e. without Doc/View) MFC is just a Object oriented wrapper about win32 that makes things easier without preventing anything.
Of books in MFC I recommended: Jeff prosise: Programming Windows with MFC.
I have yet to come by a really good win32 book.
Jacob Marner, M.Sc.Console Programmer, Deadline Games
quote: Original post by felonius
* If you use the Document/View architecture (which is not required) then the application usually gets slower - so the Doc/View archiecture is not good is speed is vital.
Out of curiosity - what exactly is it in this paradigm that makes it inherently slow?
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
>> Out of curiosity - what exactly is it in this paradigm that makes it inherently slow?
Well, the idea is that the Document (the program data), the view (the interface) and the input are completely seperated by design. These elements are then propagated around in the framework. To make this work with OLE/ActiveX and other technologies I guess the overhead just gets very high. So I guess the paradigm itself isn't bad or slow - it is just slow in MFC because of the many things it want to incorporate.
But anyway, this slowdown isn't as much an issue as it was years back when you could easily recognize a Doc/View program on its slowness. And that said, it must be noted that many Windows programs today are written in MFC with the Doc/View framework without too much trouble.
My point was that if you are writing a game and the GUI part of it plays a relatively little role then it might be an overkill to use Doc/View and you are better off without it.
Also the Doc/View framework is the part of MFC that makes you save a lot of work but it also limits you flexibility. For instance, the Doc/View framework can make saving and loading of data files almost automatic and it can create much of the functionality of standard Windows menus for you.
[edited by - felonius on May 22, 2002 8:41:31 AM]
[edited by - felonius on May 22, 2002 8:42:10 AM]
Well, the idea is that the Document (the program data), the view (the interface) and the input are completely seperated by design. These elements are then propagated around in the framework. To make this work with OLE/ActiveX and other technologies I guess the overhead just gets very high. So I guess the paradigm itself isn't bad or slow - it is just slow in MFC because of the many things it want to incorporate.
But anyway, this slowdown isn't as much an issue as it was years back when you could easily recognize a Doc/View program on its slowness. And that said, it must be noted that many Windows programs today are written in MFC with the Doc/View framework without too much trouble.
My point was that if you are writing a game and the GUI part of it plays a relatively little role then it might be an overkill to use Doc/View and you are better off without it.
Also the Doc/View framework is the part of MFC that makes you save a lot of work but it also limits you flexibility. For instance, the Doc/View framework can make saving and loading of data files almost automatic and it can create much of the functionality of standard Windows menus for you.
[edited by - felonius on May 22, 2002 8:41:31 AM]
[edited by - felonius on May 22, 2002 8:42:10 AM]
Jacob Marner, M.Sc.Console Programmer, Deadline Games
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement