?? apivsmfc.html
字號:
<HTML><LINK HREF="style.css" REL="STYLESHEET" TYPE="text/css"><HEAD><TITLE>Win32 Tutorial - Why you should learn the API before MFC</TITLE></HEAD><BODY><FONT SIZE="-1">[ <A HREF="./index.html">contents</A>| <A HREF="http://www.winprog.org/">#winprog</A>]</FONT><HR><H1>Why you should learn the API before MFC</H1><H2>The Controversy</H2>Too many people come on to IRC and ask "What is better, MFC or API?" and too many peopleare 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.<P>The standard arguments are:<UL><LI>API is too hard<LI>MFC is too confusing<LI>API is too much code<LI>MFC is bloated<LI>API doesn't have wizards<LI>MFC is badly designed<LI>API isn't Object Oriented<LI>MFC kicked my dog<LI>API stole my girlfriend</UL>And so on...<H2>My Answer</H2>My opinion, although by no means the only one, is that you should use the right frameworkfor the right job.<P>First of all a clarification on what the API and MFC are. API is a generic term meaningApplication Programming Interface, however in the context of Windows programming, it meansspecifically the Windows API, which is the lowest level of interaction between applicationsand the windows operating system. Drivers of course have even lower levels, and differentsets of function calls to work with, but for the vast majority of windows development this is not an issue. MFC is a <I>Class Library</I>, it's a bunch of C++ classes that have beenwritten to reduce the amount of work it takes to do certain things with the API. It alsointroduces an (arguably) Object Oriented framework into the application that you can eithertake advantage of or ignore, which is what most beginners do since the framework isn'treally aimed at writing MP3 players, IRC clients or games.<P>Every program, whether it is written with MFC, Delphi, Visual Basic, perl, orany other wacked out language or framework you can think of, is eventually built upon the API. In many cases this interaction is hidden, so you don't deal directly with theAPI, the runtime and support libraries do it for you. Some people ask, "MFC can do Blah Blah 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 considerablymore code than using the pre-written MFC classes.<P>So what is the right framework? For starters, for people that are just learning to program,I strongly believe that you should work with the API untill you are comfortable with theway windows applications work and you understand all of the basic mechanics behind things likethe message loop, GDI, controls, and maybe even multithreading and sockets. This wayyou will understand the fundamental building blocks of all windows applications, and canapply this common knowledge to MFC, Visual Basic, or whatever other framework you choose to work with later. It's also important because these other frameworks don't support everythingthat the API does, simply because it does a whole lot and they can't necessarily supportall of the arcane little things that most people won't use. So when you finally do needto use them you need to add it yourself, you can't rely on the framework to do it for youand if you don't understand the API this could be quite the chore.<P>But isn't MFC easier? In a certain sense it's easier in that many common tasks are done foryou, thus reducing the amount of code that you need to actually type. However, less codedoes not mean "easier" when you don't understand the code you DO need to write, or howall of the code that is there to support you actually works. Generally beginnerswho use the wizards to start there applications have no idea what most of the generatedcode does, and spend a great deal of time trying to figure out where to add things, orwhat 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.<P>Another important factor is that most people that are learing the Win32 API for the firsttime don't already have a strong base in C++. To try and comprehend windows programmingwith 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 alreadyknew either C++ or the API.<H2>So basically...</H2>What it comes down to is that I think you should 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 youtime, then by all means use it.<P><B>However, and this is important</B>... if you work with MFC without understanding the APIand then ask for help with something, and the answer you get is stated using the api (suchas "Use the HDC provided in the WM_CTLCOLORSTATIC message") and you say "huh?" because you don't know howto translate an API subject into MFC on your own, then you are in trouble and people willget frustrated with you for not learning what you need to know before you try and use MFC.<P>I personally prefer to work with the API, it just suitsme better, but if I were to write a database frontend, or a host for a set of ActiveX controls I would seriously consider using MFC, as it would eliminate a lot of code thatI would need to reinvent otherwise.<HR><FONT SIZE="-1">Copyright © 1998-2003, Brook Miles (<A HREF="mailto:forger(nospam)winprog.org">theForger</A>). All rights reserved.</FONT><SCRIPT language="JavaScript"><!-- var re = /\(nospam\)/ig; var str; for(i = 0;i < document.links.length;i++) { str = "" + document.links(i).href; if(str.search(re) != -1) document.links(i).href = str.replace(re, "@"); str = "" + document.links(i).innerHTML; if(str.search(re) != -1) document.links(i).innerHTML = str.replace(re, "@"); }--></SCRIPT></BODY></HTML>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -