Gerber is great, that doesnt mean I want it for lunch.
So now you are insulting people, too.
Yeah, C#, Java, C++, D, Python, Pearl, PHP is crap and should never have been invented.
C rules and is the only language we ever need.
All else is superfluous and anyone who can't use it or do it well are morons that needs to be shot.
And because C rules we don't need crap like MFC, Qt, wxWidgets. We only need the raw API because it rulez and everything else sucks.
Wow, I can see you completely missed the point. Didn't I just get done saying that MFC is better than the API at GUI? So now you imply that im some sort of zealous language bigot hell bent on eradicating coding in anything but 1's and 0's using a car battery and a 27C16.
If you say so.
I would still, however, say that frameworks are better than the API, because the API is a mess.
A framework can correct flaws and create a more pleasing environment for many.
I do NOT think you should diss MFC to only those incapable of using the Windows API.
Well that is where we disagree. I believe that those capable of getting closer to the metal should do so as ultimately they will find it a much more rewarding and productive experience.
ROFLMAO, elysia, the api is simpler and more straight forward than MFC any day of the week. It's about as user friendly as you can get, I have no idea where you get off implying that MFC is in any way shape or form user friendly.Statistical distribution of intelligence and skill level in the programmer base?
Gerber is great, that doesnt mean I want it for lunch.Time and time again in threads with Elysia you attempt to prove your point by personal attacks. This is very tiresome and an extremely immature form of debate. If you and Elysia have issues may I suggest you sort them out outside of otherwise peaceful threads.No I wont even go near that can of worms. You clearly win in the ego contest. I merely state the fact that I am smarter than 98% of the human race, you think you are a god.
And now to the original question:
My opinion is that MFC is indeed simpler than pure Win32 API. If that makes me a crappy C++ programmer then so be it...I'm a crappy C++ programmer.
Any opinion here is going to be just that. In order to find out for yourself which is easier you will have to gain some experience with both.
Last edited by VirtualAce; 06-30-2008 at 05:39 PM.
For me, by chance, I started Windows programming with MFC first. At that time, I was a simple *user* of the framework. Doing something that I'd never done before required hitting the reference material and hopefully finding complete samples that demonstrated what I was looking for.
Then I got Petzold, and started learning the overall concepts in the Win32 API that MFC "took care of" for me. Once I started understanding how the framework itself worked on top of the Win32 API, I no longer felt like a simple user. Doing something new no longer required samples; just reading the MSDN pages on per-MFC object basis was enough to get going.
A lot of MFC isn't just a simple wrapper of the raw API - and those parts of MFC I ended up learning last - by virtual of buying and reading an MFC book (document-view arch. comes to mind). And there are other parts of the framework that I've never touched.
Based on my experience, I used to advocate learning the raw API first, so that you can understand and appreciate what MFC is "taking care of for you" - which would hopefully make for a faster tract towards mastering the framework.
In the end, I think that if you want to *master* MFC (at least the portions of the framework that wrap raw API's), then the raw API should be learned at some point.
However, I no longer advocate learning one before the other. I think that really depends on your personal short-term and/or long-term goals.
I learnt WIN32 then MFC.
I still use both, in the most apps I write.
Somethings can't be done in WIN32 and many things are quicker with MFC.
As Codeplug said, depends where you want to take your programming.
Hobbist would probably be better with MFC and somer WIN32.
Career, I would recommend a much deeper understanding of WIN32, it will force you to write better code (and allow you to bypass the limitations of MFC as required).
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
"If you are going through hell....keep going."
Err... may I suggest neither MFC or Win32 API?
I'm honestly unsure where these two will lead and if at this point it pays to learn them. Probably Win32 API will be around for quiet a while still, but definitely I wouldn't put much effort in learning MFC at this point since Microsoft clearly wants to get rid of it as soon as it can.
The .Net Framework is a viable and more intelligent alternative to MFC. Viable because it apparently does a better job at streamlining code development than MFC ever did, and intelligent because this is the route Microsoft wants you to take. My gripe with .Net derives solely from the fact I strongly believe this thing should have been built with C++ in addition to C# (if they really had to create C#, in the first place. But that's an altogether different discussion).
The other option, in case you want to stick to C++ programming, is to learn one of the 3d party libraries available to you. These are extremely good up-to-date libraries that simplify your windows code considerably when compared to MFC (and provide a lot more features). They are also much easier to learn and more more intuitive to use. But more important, they are portable across different OSes. WxWidgets and Qt are the most used ones. I prefer wxWidgets and have been playing around with Qt too.
WxWidgets seems to me more mature and with more features. But started out in a time when the STL was in its infancy, for which reason it doesn't provide native support for STL types. It doesn't mean you can't use them. Just that it will be a little more awkward to do so, since wxWidgets uses instead its own STL-like objects and you will be constantly casting between types. It's my pet-peeve with wxWidgets, despite being my favorite library. I don't think there's anything you can't do in windows with it.
Qt is a much more... modern(?)... approach to windows development. It fully supports STL, thank goodness, it outperforms (in my opinion and after only preliminary observations) wxWidgets in several important areas like grid and list controls, screen rendering and multi-threading. Its licensing system however demands money if you want anything above some basic functionality. It also comes behind in number of features when compared to wxWidgets.
Personally I would either go with C# or one of those two libraries. After you build some confidence, I only then suggest you learn Win32 API. For one you will be then more motivated to do so. But most importantly, you will also be better prepared to understand some of the gritty details. Not that you can't learn the API without all that baggage behind you, just that it will be easier and probably more fun.
Finally... a disclaimer:
I'm not really saying MFC is not an option - I think a large chunk of windows programming is still done in MFC. On the other hand skills in MFC should still be a priority if you are interested in learning windows programming with a career in mind. In that case, definitely forget about 3rd party libraries for now... unfortunately, I say. And go all the way C# on one hand and MFC on the other, with Win32 API as soon as you feel more or less comfortable.
But I do argue the future of MFC, though. And if you are not immediately pressed, don't go that route.
Last edited by Mario F.; 06-30-2008 at 08:42 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
This forum cares about portability. And it's not a kid concept.
But I would like to say steer away from C# and any dotNet, because IMO, it's a mistake. Plus it will probably not be very portable, and still isn't very portable.
They are slow and bloated. The borderline between low level programming and dotNet is, well, C++. With the right tools and libraries, we can maintain performance, efficiency, and still write good applications.
Of course, if you're considering real-world application, you may be forced to go down the path of dotNet, because companies don't really care if it's slow or bloated as long as it takes less time to write an application.