- Forum
- Windows Programming
- API || MFC
API || MFC
Hello everybody.
I'm starting to learn window programming using visual studio, but I found that there is 3 different ways to learn windows programming
1- MFC
2- API
3- Windows form (which for CLI)
I don't know how to write codes for C++/CLI so I omit the third choice, but still don't know which is better from the first and second choices.
SO, HELP ME PLEASE.
I'm starting to learn window programming using visual studio, but I found that there is 3 different ways to learn windows programming
1- MFC
2- API
3- Windows form (which for CLI)
I don't know how to write codes for C++/CLI so I omit the third choice, but still don't know which is better from the first and second choices.
SO, HELP ME PLEASE.
Commercially speaking, there's a lot out there done in MFC.
Personally speaking, I have never liked MFC very much so I have never learned it, and find that pure WinAPI isn't all that bad. I have come to realize that much of my grief used to come from managing memory buffers. Now that I really know C++, I don't find the memory management chore boring or "bad".
Still, I'm not against Windows frameworks. It is just MFC that doesn't look too nice to me. For instance, I ADORE .net's Windows Forms (but in C#, not C++/CLI).
Personally speaking, I have never liked MFC very much so I have never learned it, and find that pure WinAPI isn't all that bad. I have come to realize that much of my grief used to come from managing memory buffers. Now that I really know C++, I don't find the memory management chore boring or "bad".
Still, I'm not against Windows frameworks. It is just MFC that doesn't look too nice to me. For instance, I ADORE .net's Windows Forms (but in C#, not C++/CLI).
closed account (z05DSL3A)
It is all built on top of the Windows API, so I guess it depends on how you like to learn.
If you like getting down to the grass roots and working your way up with a thorough understanding of what is going on, start with the Windows API.
On the other hand; if you like learning the general overview of things without knowing what is going on under the hood, Start with MFC or the .net framework.
If you like getting down to the grass roots and working your way up with a thorough understanding of what is going on, start with the Windows API.
On the other hand; if you like learning the general overview of things without knowing what is going on under the hood, Start with MFC or the .net framework.
Last edited on
I've a little discussion about the whole thing here you might find useful...
http://www.jose.it-berater.org/smfforum/index.php?topic=3389.0
From my reading of discussions here at cplusplus.com over the past couple years what I have learned is that most or at least a lot of new C++ coders, when confronted with the Win32 Api and SDK style GUI programming for the first time, are somewhat 'put off' by its low level 'C' nature. No doubt they've struggled mightily to learn such things as console i/o with iostream, classes, STL, etc., and nowhere is any of that to be found. Real culture shock!
But they'll dig up some SDK templates from somewhere on the net and have a go at it! Since every C++ program they've ever seen anywhere has an #include <iostream> and a using namespace std at the top, they'll dutifully throw that in there, even though it accomplishes little. Of course, strings are very important in any programming, but all of a sudden they find out the Api functions don't know anything about the STL based Std. Lib's string class. So they end up in one world of hurt pretty fast.
I think that's why a pretty lot go the class framework route. It seems more C++ like. But I'm with webjose. I like allocating memory, checking for buffer overruns, de-allocating memory, etc. I believe coding is hard work, and I've never found an easy way to get good results that doesn't have a lot of drawbacks.
http://www.jose.it-berater.org/smfforum/index.php?topic=3389.0
From my reading of discussions here at cplusplus.com over the past couple years what I have learned is that most or at least a lot of new C++ coders, when confronted with the Win32 Api and SDK style GUI programming for the first time, are somewhat 'put off' by its low level 'C' nature. No doubt they've struggled mightily to learn such things as console i/o with iostream, classes, STL, etc., and nowhere is any of that to be found. Real culture shock!
But they'll dig up some SDK templates from somewhere on the net and have a go at it! Since every C++ program they've ever seen anywhere has an #include <iostream> and a using namespace std at the top, they'll dutifully throw that in there, even though it accomplishes little. Of course, strings are very important in any programming, but all of a sudden they find out the Api functions don't know anything about the STL based Std. Lib's string class. So they end up in one world of hurt pretty fast.
I think that's why a pretty lot go the class framework route. It seems more C++ like. But I'm with webjose. I like allocating memory, checking for buffer overruns, de-allocating memory, etc. I believe coding is hard work, and I've never found an easy way to get good results that doesn't have a lot of drawbacks.
I personally prefer ATL/WTL and straight win32api instead of MFC.
I like to control and know how things work, which you cannot do with a framework like MFC or .net
I like to control and know how things work, which you cannot do with a framework like MFC or .net
Topic archived. No new replies allowed.