• Advertisement

Archived

This topic is now archived and is closed to further replies.

Which is better? WIN32 or MFC

This topic is 5755 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

It seems that nowadays more and more developers are going for MFC and otherwise for WIN32. Is it that WIN32 is becoming outdated?

Share this post


Link to post
Share on other sites
Advertisement
The problem with MFC is code bloat.. you suddenly find yourself including the kitchen sink when all you wanted to model was the dishcloth.

If you want a lean mean piece of code, WIN32 is the way to go.. but these days with lots of system memory, lots of disk space and big pressures to produce content fast - programmers get lazy.They think why invent the wheel even though the car gets thrown in too.

The disadvantage is working through microsoft''s entangled MFC API. Great if you want to do something common, but the API isnt flexible enough if you want to push an envelope.

Thats my experience anyhow.

Share this post


Link to post
Share on other sites
MFC is merely a Win32 wrapper. Do the logic from there.

MFC is convenient, but it''s showing its age. Also, since C++ has matured a lot since MFC inception a lot of the workarounds and emulated features have been better implemented in the language itself. The logical successor to MFC is the Windows Template L ibrary (WTL), except that Microsoft released that baby as a completely undocumented and unsupported collection of template source files and an MSVC AppWizard. The Code Project hosts an effort to document this much better structured API, and are meeting with some success.

However, (and you knew this was coming) Microsoft seem to have neither interest nor reason for interest in further Win32 API GUI development. The introduction of GDI+ and WinForms could possibly signal the end of MFC/WTL, provided there are means for dynamically creating WinForms objects at runtime in code.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! | Asking Smart Questions | Internet Acronyms ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
Win32 is generally better if you want to make games, but MFC is better if you're working on a deadline or making a strictly windows GUI based program. I would reccomend learning MFC because so many employers want you to, plus it's a good way to become truly proficcent in using classes to the fullest.

Pros:
-MFC will prevent a lot of the mistakes that can happen when programming Win32 (ex. Releasing bitmaps is done automatcally)
-Large MFC applications will use around one third of the number of lines of code you write in the Win32 equivalent.

Cons:
-Can be very hard to follow (because of heavy inheritence)
-MFC is a layer on top of Win32, thus it generally runs 'slightly' slower, and takes up 'slightly' more space.

Learn it, there is no reason to neglect learning something new.

[edited by - Mulligan on April 18, 2002 2:31:30 PM]

Share this post


Link to post
Share on other sites
May be I''m still new to Windows Programming but is it true that WIN32 is the main engine that powers the Windows OS? and now, what we have are two ways of programming for Windows.






The road may be long, wind may be rough. But with a will at heart, all shall begone. ~savage chant

Share this post


Link to post
Share on other sites
More developers are going for MFC? Where did you hear that? I can''t believe a Game developer would even consider MFC.

Share this post


Link to post
Share on other sites
quote:
Original post by Mulligan
I would reccomend learning MFC because... it''s a good way to become truly proficcent in using classes to the fullest.

Um, no.

MFC requires way to much inheritance, and inheritance is generally overused (so says Herb Sutter, so you should listen). It also uses a bunch of very dirty macro methods to bind Windows messages to class methods (AFX_MESSAGEMAP_BEGIN, AFX_MESSAGEMAP_END). While WTL is cleaner and better structure, it too uses these macros.

quote:

MFC will prevent a lot of the mistakes that can happen when programming Win32 (ex. Releasing bitmaps is done automatcally)

Using an auto pointer-esque container will handle this. Simply write one for Win32 HANDLEs/GDIOBJs. ATL already provides CComPtr and CComQIPtr, so I no longer release COM interfaces (e.g. DirectX) manually. Ever.

quote:

Large MFC applications will use around one third of the number of lines of code you write in the Win32 equivalent.

True. And this is the reason why MFC is so popular. In one case I heard of, a procedure that required over 100 lines of code in "naked" Win32 was accomplished in one MFC function call.

quote:

Learn it, there is no reason to neglect learning something new.

I''d say be familiar with it. I''d also advcate WTL as a "better MFC".

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
quote:
Original post by savagerx
May be I''m still new to Windows Programming but is it true that WIN32 is the main engine that powers the Windows OS?

Not exactly. Win32 is an extensible collection of header files and libraries (static and dynamic) for programming the Windows OS. The OS itself is partly written in Win32, but lower level stuff is just written in C and C++ (and assembly).

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
although i am somewwhat inexperienced with MFC, i like it because its already object oriented. the win32 api is C-e, so you often end up writting your own wrappers and things. with MFC, you can just use a tad of composition here and there, and your windows engine is there, done, and fits nicely into your system.

Share this post


Link to post
Share on other sites
Ok, let''s get something straight.

MFC stands for Microsoft Foundation Classes.

These are a collection of classes that wrap the Win32 API.

Any application that runs on Windows is going to use the Windows API. You can''t get around it. Event MS''s STL and Standard C/C++ library implementations are just higher level wrappers of the Windows API (if you dig deep enough).

The point is, you can use Win32 and not use MFC. But you can''t, I repeat, CANNOT use MFC without using the Win32 API.

Share this post


Link to post
Share on other sites
quote:

Originally posted by daerid:
Event MS''s STL and Standard C/C++ library implementations are just higher level wrappers of the Windows API


STL and the standard C/C++ library are by no means wrappers of the Windows API.

Forever trusting who we are
And nothing else matters
- Metallica

Share this post


Link to post
Share on other sites
quote:

STL and the standard C/C++ library are by no means wrappers of the Windows API.



actually, you're halfway correct. STL is a c++ library that uses the standard C runtime library to implement most of it's functionality.

I'm pretty sure that the standard malloc() function somewhere down the line actually calls HeapAlloc().

That standard c runtime library is implemented based on what operating system it's running on. I don't know exactly how it works on a unix/linux based system, but I know that on Windows, the CRT is a wrapper of the Windows API that conforms to the C standard, to allow for portable code.

Do me a favor and step through this code using VC++ (f11):


      
#include <iostream>
#include <fstream>
#include <string>

int main(int argc,char** argv)
{
std::ofstream outfile;
outfile.open("Test.txt");
outfile << "Blah" << std::endl;
outfile << "More blah" << std::endl;
outfile.close();

std::ifstream infile;
infile.open("Test.txt");
std::string line;
std::getline(infile,line);
std::cout << line << std::endl;
std::getline(infile,line);
std::cout << line << std::endl;

infile.close();

remove("Test.txt");

return 0;
}


Along the way, you'll see a whole lot of Win32 API calls, with CloseHandle() and CreateFile() being the one's to look out for.

Those are documented Win32 API functions.

The API is the interface to the operating system. It's how you talk to it.

[edited by - daerid on April 19, 2002 12:28:58 PM]

[edited by - daerid on April 19, 2002 1:19:54 PM]

Share this post


Link to post
Share on other sites
i''m no STL evangelist. but, you should''nt think of STL as a wrapper, because it''s not . it is not defined in terms of the Win32 API. for starters it runs on other platforms. this is simply the way MS implemented it under Win32.

if you''re going to make a statement, make it clear and definitive. i.e. STL is implemented through Win32 function calls for MS VisualStudio.

To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.

Share this post


Link to post
Share on other sites
your code is really specific -it uses file io and graphics.
obviously you will need to make win32 api calls to TALK TO WINDOWS, which is what the implementation of classes like iostream do, under win32. the implementation of the libraries may be different under different oses.

Share this post


Link to post
Share on other sites
quote:
Original post by jenova
.... this is simply the way MS implemented it under Win32.

if you're going to make a statement, make it clear and definitive. i.e. STL is implemented through Win32 function calls for MS VisualStudio.




I apologize if what I said was in someway ambiguous, but basically all I'm saying is that if you're going to run a program on Windows, you're going to be using the Windows API.

Either directly, or indirectly. Even operators new and delete on Windows are implemented using the run-time library, which is based around the Window memory management API.

[edited by - daerid on April 19, 2002 1:29:03 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Pardon me, but I think that piece of code is console based right?

Share this post


Link to post
Share on other sites
That's beside the point.

It will still run on windows, and when it DOES run on windows, it has to use the API.

*edit* Directed towards Anon

[edited by - daerid on April 19, 2002 1:44:56 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Gabriel Fleseriu
My point was: STL might USE the WinAPI, but it does not WRAP it.




might is the keyword here.


quote:
Original post by daerid
That''s beside the point.

It will still run on windows, and when it DOES run on windows, it has to use the API.




this is NOT necessarily true. MS or some other vendor could have written ".VxD''s", ".DLL''s", or ".sys" files to directly interface with the hardware for use with STL. in this instance with MS VisualStudio, Win32 API calls are used because the framework is already there.. but, it is not an absolute true statement to say; STL has to use the Win32 API.

To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.

Share this post


Link to post
Share on other sites
That''s correct, I was overlooking custom .dll''s and .vxd''s

So basically it''s just that the majority of the time if you run a program on windows, you use the API.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
After reading through the forumn, I have 2 enquiries.

Firstly, since MFC is so popular, therefore, does it signal that the market for WIN32 is becoming smaller than ever?

Lastly, regarding the wrapper for WIN32, is there any tutorial on the net that address to the issue?

All comments are welcomed. Thanks

Share this post


Link to post
Share on other sites
Well, realize that MFC is a c++ abstraction of Win32.

So if the market for MFC increases, then the market for Win32 increases as well. They''re both directly related/connected.

Share this post


Link to post
Share on other sites

  • Advertisement