Why do I first learn API before learning MFC? (Translated)

Why you shoshould learn the API before MFC
Why do I first learn API before learning MFC?

Original article: http://www.winprog.org/tutorial/apivsmfc.html
Liu Jianwen translated (http://blog.csdn.net/keminlau) the controversy argument

Too users people come on to IRC and ask "What is better, MFC or API? "And too recommend people are willing to say" MFC sucks "or" API sucks "either because of traumatic events involving one or the other in early childhood, or because everyone else is saying it.

Many people ask the following question: Which one is better for both MFC and API? There are more replies: "MFC is too bad" or "API is too bad ". Most of the reasons for being biased are because they have had a bad first impression on the two, and the psychological "injury" leaves a shadow. Or they just hear others' comments, and the cloud is everywhere.

The standard arguments are: Typical arguments are as follows:
* API is too hard
* MFC is too confusing
* API is too much code
* MFC is bloated
* API doesn' t have wizards
* MFC is badly designed
* API isn' t Object Oriented
* MFC kicked my dog
* API stole my girlfriend

And so on...

My answer my answer

My opinion, although by no means the only one, is that you should use the right framework for the right job.

My only point is that you need to select an appropriate framework (API or MFC) for your work ).

First of all a clarification on what the API and MFC are. API is a generic term meaning application programming interface, however in the context of Windows programming, it means specifically the Windows API, which is the lowest level of interaction between applications and the Windows operating system. drivers of course have even lower levels, and different sets of function CALS to work with, but for the vast majority of Windows development this is not an issue. MFC is a class library, it's a bunch of C ++ classes that have been written to reduce the amount of work it takes to do certain things with the API. it also introduces an (arguably) Object Oriented Framework into the application that you can either take advantage of or ignore, which is what most beginners do since the Framework isn' t really aimed at writing MP3 players, IRC clients or games.

First, let's clarify what is API and MFC. An API is an "Application Programming Interface", which is the boundary for the interaction between an application and the operating system. It is quite an "underlying" thing. It is more "underlying" than the API, of course, the number of drivers, it directly interacts with the hardware. MFC is a C ++ class library designed to reduce the amount of code that uses APIs to write specific functions. MFC also brings an object-oriented framework for application development. You can decide whether to use oo. Many beginners use oo because the framework is not originally intended to write MP3 players, IRC clients, or games.

Every program, whether it is written with MFC, Delphi, Visual Basic, Perl, or any other wacked out language or framework you can think of, is eventually built upon the API. in your cases this interaction is den, so you don't deal directly with the API, the runtime and support libraries do it for you. some people ask, "MFC can do blah, can the API? "The answer is that MFC can only do what the API can do, because it's built on top of it. however doing things yourself with the API may take considerably more code than using the pre-written MFC classes.

No matter what language or framework programs are used, they are finally built on the API. In many cases, interaction with APIS is hidden, so you do not have to deal with APIs directly. runtime or code library will work for you. Because MFC is built on the API, the API that MFC can do is acceptable, and vice versa. Of course, the price for API flexibility is the huge increase in the number of codes.

So what is the right framework? For starters, for people that are just learning to program, I stronugly believe That you shoshould work with the API untill you are comfortable with the way Windows applications work and you understand all of the basic mechanics behind things like the message loop, GDI, controls, and maybe even multithreading and sockets. this way you will understand the fundamental building blocks of all Windows applications, and can apply this common knowledge to MFC, Visual Basic, or whatever other framework you choose to work with later.

So what is a suitable framework? For beginners, they only learn programming skills. I strongly recommend that you learn the API mechanism from the beginning until you know the working principle of the window application well, it includes the basic mechanisms of message loops, GDI, controls, multithreading, and sockets. This method allows you to understand the working principle of basic construction blocks of Windows applications and apply these general knowledge to different framework codes such as MFC and VB. (Kemin: the fundamental building blocks) is an organic element of the application framework. Different [Application Frameworks] use different basic construction blocks. To develop a GUI, fbb, such as message loops, GDI, controls, and multithreading, must be mastered no matter what GUI application framework you learn .)
(Kemin: Also, it can be seen from here that the API is universal, while the MFC is a special implementation; The principle of GUI development or the theory of GUI development framework is universal; frameworks such as MFC and WCL are special implementations. We need to learn something universal .)

It's also important because these other frameworks don't support everything that the API does, simply because it does a whole lot and they can't necessarily support all of the arcane little things that most people won't use. so when you finally do need to use them you need to add it yourself, you can't rely on the framework to do it for you and if you don't understand the API this cocould be quite the chore.

Another important reason for learning APIS is that the framework does not support the functions supported by all APIs. The reason is simple. The framework only encapsulates the common functions required by those applications. The cost of encapsulation is the reduction in flexibility.

But isn' t MFC easier? In a certain sense it's easier in that same common tasks are done for you, thus cing the amount of code that you need to actually type. however, less code does not mean "easier" when you don't understand the code you do need to write, or how all of the code that is there to support you actually works. generally beginners who use the wizards to start there applications have no idea what most of the generated code does, and spend a great deal of time trying to figure out where to add things, or what changes to make to acheive a certain result. if you start your programs from scratch, either in the API or with MFC, then you know where everything is because you put it there, and you will only use features that you understand.

However, isn't MFC simpler? In a sense, yes. MFC facilitates your common development work and reduces the amount of code required for development. However, missing code does not mean "simple. You don't understand the specific mechanism inside the black box. Your capabilities are very limited.

Another important factor is that most people that are learing the Win32 API for the first time don't already have a strong base in C ++. to try and comprehend windows programming with MFC and learn C ++ at the same time can be a monumental task. although it's not impossible, it will take you considerably longer to become productive than if you already knew either C ++ or the API.

The third important reason for learning programming from Win32 API is that it helps to learn C ++. It is recognized that it is quite difficult to learn C ++, but if it has an application, it will be very good, and learning C ++ and API together is an arrow.

So basically...
What it comes down to is that I think you shoshould learn the API untill you feel comfortable with it, And then try out MFC. if it seems like it's making sense to you and saving you time, then by all means use it.

The conclusion is that you should first learn the API until you are quite familiar with it and then learn MFC.

However, and this is important... if you work with MFC without understanding the API and then ask for help with something, and the answer you get is stated using the API (such as "use the HDC provided in the wm_ctlcolorstatic message") and you say "huh? "Because you don't know how to translate an API subject into MFC on your own, then you are in trouble and people will get frustrated with you for not learning what you need to know before you try and use MFC.

I personally prefer to work with the API, it just suits me better, but if I were to write a database frontend, or a host for a set of ActiveX Controls I wowould seriously consider using MFC, as it wowould eliminate a lot of code that I wowould need to reinvent otherwise.

I personally prefer to use APIs because they are more suitable for me. However, if I want to write a data front-end or Host Program of an ActiveX control, I do not hesitate to choose to use MFC.