Printable View
I want to know how many people actually use MFC that post on these boards. I just want to get an idea how popular it is, but also if there are a lot of people to help me with it (the real reason)
I would think that most people that know the winapi also have at least a fair understanding of Visual C++ with MFC.
MFC is bad; the api is better.Quote:
MFC: Keeping programmers stupid
I use it for some stuff...and a lot of people do (go to codeguru or codeproject and you'll see)......many people dont, and that's their decision....a lot of it is down to what you want and what you want to do...
But beware negative opinions from people who have no knowlege on MFC whatsoever.......If they can use MFC and still dont like it - ok, but if they have no knowlege on it and dimiss it out of hand you can safely ignore them
hey! I know you can hear me! Oh fine then...just keeping ignoring me... !!
*storms out of room*
[quote by Fordman]
a lot of it is down to what you want and what you want to do...
[/quote
Umm well...can't you do basically everything with MFC? I want to be able to just make windows applications! These will include simple databases for the most part, using dlls and internet stuff.
I would have used it for ActiveX if ATL had not come along. But I never found it to be easier than straight API. The whole thing is very much a thin wrapper and it seems you're doing just as much work. Plus I have a real problem with macro heavy code. When you statically link (the only way I would even consider) you bloat the app when its not necessary to. I don't know. I can't say that someone is stupid for using it but I don't.
Thats exactly the point: you cant do everything -- they're trying to control what you can do by introducing a seemingly easier way to get the same thing done, but by doing so you lose the ability to customise you lose POWER!Quote:
Umm well...can't you do basically everything with MFC? I want to be able to just make windows applications! These will include simple databases for the most part, using dlls and internet stuff.
*gets ignored ... again*
That is too dumb to deserve a detailed response....Quote:
Originally posted by face_master
Thats exactly the point: you cant do everything -- they're trying to control what you can do by introducing a seemingly easier way to get the same thing done, but by doing so you lose the ability to customise you lose POWER!
*gets ignored ... again*
Yeah..its good for creating windows quickly...has a lot of COM abilities like for automation and database stuffQuote:
Originally posted by Shadow12345
[quote by Fordman]
a lot of it is down to what you want and what you want to do...
[/quote
Umm well...can't you do basically everything with MFC? I want to be able to just make windows applications! These will include simple databases for the most part, using dlls and internet stuff.
Give it a try and make up your own mind :)
Ive used it in the past but my preference is for straight API. Some of the MFC was nice but I think that some of it has a lot of bloat in it and thus is undesierable. But I do use my own wrappers for the part of the API im using since im a big fan of OOP and hate to read spaghetti code.
I use it for almost all my win projects. I like it alot but there is to much macros in it..Although if I would start over I would rather spend my time with managed C++ and the .NET framework then with mfc.
>> That is too dumb to deserve a detailed response....
As is most of the stuff that I post
Another vote for MFC here. I haven't done much windows programming and none at all with the api on its own. I started off with MFC so thats what I find easiest, the object oreinted nature (however thin it maybe) really helps when learning to control a window with toolbars, status bars, dialogs, menus, etc, etc.
I prefer API although I have used mfc in the past to see what all the fuss was about and because I had read the 'industry standard' label applied to its use (MCSD courses seem to be nothing else).
As has been already stated, MFC is a thin wrapper around the API and seems to involve as much hassle to use as just using the API neat. I also recall having a hassle with CFont objects (for example) not releasing gdi resources back to the system...(this may have been cured, though).
It seems to me that learning API will do more good than just relying on mfc - there are some things that may be achieved using only API eg there is no DIB class in MFC (msvc6), the CBitmap class is device dependant.
>>But I do use my own wrappers for the part of the API im using since im a big fan of OOP and hate to read spaghetti code.<<
Me too - still have spaghetti code, though. ;) I'd also add that it's arguably a useful challenge in OOP design to coerce the API into a sensible C++ wrapper(s) of your own. On a personal level I never did learn to let go of my reliance on the windowsx.h message macros. :(
I'm also an amateur - this is a hobby so there's no pressure on me to choose one over the other. Lucky me. :D
i use MFC only when im to damn lazy to learn the WinAPI i need to code something, but then i get so ........ed at trying to get the MFC to work i end up forgrting the original purpose of the program, and quiting after my small triumph over MFC.
in short, only use MFC for the simplest things, or maybe im just stupid.
either way, Trog no like.
BTW: to those who seem to be refering to procedural programming in general as spagetti code, i strongly disagree OOP has a tendancy to be infinitly more complex, badly designed, and "spagettish" if it is not PRE-DESIGNED and implemented properly. (STESS on PRE-DESIGN!!! i get ........ed at poorly designed OOP's especialy since i already hate OOP, and that just makes it a milion tmes worse)