MFC - good or bad?

No i hope you''ve got the RIGHT opinion, because i will follow your suggestion. I thought there was something "wrong" with, MFC, and oviously, there are...

Thx!

/Andreas

While its true, MFC is absolutely evil... there are a few things that are quite handy...
unfortunately though, when you use MFC, you load a ton
of other useless shit as well...
unneeded overhead on any application imho...
if i were you i''d stick with STL..


-eldee
;another space monkey;

quote:

---

Original post by Norge
No i hope you''ve got the RIGHT opinion, because i will follow your suggestion. I thought there was something "wrong" with, MFC, and oviously, there are...

Thx!

/Andreas

---

the only thing wrong with MFC is that it adds unecessary overhead
to your applications. and that the m stands for microsoft.


-eldee
;another space monkey;

If you want to make a serious application, you better use mfc or some other API higer then the win 32 API...

From my experience it was pretty easy to start using win 32, but very hard to use it in a lager context such in a bigger application. MFC is hard to use in the beginning but once you get the basics (and maybe a litle more), it is much easer and faster to program then win32 API.


// Peter... and that is what i think =)

My opinion - it is handy, and can on occasions be easier to read and code than using the Win32 API eg for GUIs. However, it does get very complex very quickly and then the evil becomes apparent

But isnt it soon to be superseeded by the .NET framework? And if so will this be any better? But this is a whole new topic...

quote:

---

Straight C++ and STL is *so* much better. Forget about MFC.

---

quote:

---

if i were you i''d stick with STL..

---

Apples and oranges ...
Since when was the STL designed to be an enterprise-level Win32 application framework? And since when was MFC designed to be a collection of extendible, generic algorithms and data structures?

Thx for your advice, guys =) I think i''ll be using STL for my future applications....

I made myself the same question after reading that



Gaiomard Dragon
-===(UDIC)===-

Why does a swede call himself Norge?

Fantastic doctrines (like Christianity or Islam or Marxism or Microsoft-bashing) require unanimity of belief. One dissenter casts doubt on the creed of millions. Thus the fear and hate; thus the torture chamber, the iron stake, the gallows, the labor camp, the psychiatric ward - Edward Abbey

I really am norwegian, but i''ve lived in Sweden for 11 years now..=)
Everyone calls me just "Norge", and that''s why i use that nick.

I use MFC for all my external config programs and whatnot, Its simple to slap togather an MFC project that dose something in a few mins. I look at it as the Visual Basic component for C++.

MFC is just a quick way of doing something complex at the cost of some serious overhead. In my opinion, its better to put together your own library of GUI objects and work off that. It''s cleaner but less standard (whatver "standard" means these days). A simple "Hello World!" program should run about 40k in win32... same thing in MFC is about 1.2 meg. That''s a lotta bytes to simply put 12 characters on the screen.

I''ll put it this way...

If I want to write a utility that the world may download (sumthin'' like WinAmp) then I use straight Win32.

If I need an editor for a game I''m working on and I need it quick, I use MFC.

- Jay

yeah, I see MFC as the RAD tool for C++, its ok until you try to use more complex controls like CTreeView, CListView, and all those other controls that in lean and mean win 32 are already complicated, for game dev purposes, in my opinion, there is no need for MFC at all.

My point wasn''t that there''s anything wrong with straight C++ and STL. It was that comparing STL and MFC doesn''t make sense, because they are two completely different things.

quote:

---

Original post by Anonymous Poster


You use straight C++ OOP to create your own (efficient and clean) Win related classes by using the Win32 API, and use STL for all the generic container classes.

---

This is known as "reinventing the wheel". Which is all good and dandy if wheel design is your primary interest. However, for the people that wants a vehicle that actually goes somewhere, reusing the existing wheel design might be a better idea.



Fantastic doctrines (like Christianity or Islam or Marxism or Microsoft-bashing) require unanimity of belief. One dissenter casts doubt on the creed of millions. Thus the fear and hate; thus the torture chamber, the iron stake, the gallows, the labor camp, the psychiatric ward - Edward Abbey

" A simple "Hello World!" program should run about 40k in win32... same thing in MFC is about 1.2 meg. "

Take it out of debug mode man.

the last config program i wrote had one button and two sets of radio buttons, its about 20k.

As was mentioned earlier - if you have incurred alot of overhead from MFC, chances are very high that you are using it incorrectly.

The last MFC app I wrote was ~100K with statically linked MFC and 20K with a shared DLL. Where is all this overhead everyone talks about??? Please explain.

It could be built a little better, but that''s true for any large API - it''s never going to be as tight as a narrow solution. However, in terms of project cost, I''d much rather have people use MFC than implement GUI classes, database classes, etc. from the raw API.

If you are using an API incorrectly, you can''t blame the API for bad results.

We develop commercial applications using MFC.

It''s ugly and I don''t like it, but I sure have better things to do than write my own Win32 API wrapper.

And I hope nobody here is trying to use it for embedded applications, so who cares about a 100k executable.

You can use MFC for games, with pretty much no overhead at all (no, you don''t have to use doc/view), but there''s no real advantage in doing so. It''s a good idea however, to use MFC (or at least some other wrapper) for your game-tools.

Thats a great site for MFC/OpenGL work, the only one I found

Just thought I''d tell everyone :D