Why you should learn the API before MFC

The Controversy

The standard arguments are:

• 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

My Answer

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 calls 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.

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 many cases this interaction is hidden, 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 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 considerably more code than using the pre-written MFC classes.

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 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. 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 could be quite the chore.

But isn't MFC easier? In a certain sense it's easier in that many common tasks are done for you, thus reducing 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.

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.

So basically...

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 would seriously consider using MFC, as it would eliminate a lot of code that I would need to reinvent otherwise.

　　不能延长生命的长度，但你可以增加生命的宽度。

　　重要的并不在于你现在的地位是多么卑微，或者从事的工作是多么地微不足道，只要你强烈地渴望攀登成功的巅峰并愿意为此付出艰辛的努力，那么总有一天你会喜笑颜开如愿以偿。

　　有什么样的目标，就有什么样的人生。

　　社会结构是一种金字塔状结构。大量的人处在金字塔的底部，只有一小部分人处在金字塔的顶部。处在底层的人们每天只能收支相抵，量入为出，只能现 挣现吃，仅够糊口。而处在顶尖的人则是蒸蒸日上，繁荣兴旺。每一个城市每一个公司，都是大多数人在底层，少数人在顶部，而处在顶部的人都是从底层逐渐上升的。

　　为什么偏偏是他们达到了众人瞩目的高度呢？

　　上帝对每个人都是公平的，希尔顿、洛克菲勒并不比你拥有的时间多一秒钟，但为什么只有他们取得了令人瞩目的成就？问题的关键就在于你没有人生的高度。

　　绝大多数人之所以平庸一生，之所以只能在历史的舞台上扮演无足轻重的次要角色——包括那些懒惰闲散的人、好逸恶劳的人、平庸无奇的人——原因就是他们缺乏内在的动力。

　　哈佛大学曾做过一个著名的实验。

　　在一群智力与年龄都相近的青年中进行了一次关于人生目标的调查，结果发现：

　　3%的人有十分清晰的长远目标；

　　10%的人有清晰但比较短期的目标；

　　60%的人只有一些模糊的目标；

　　27%的人根本没有目标。

　　25年后，哈佛大学再次对他们做了跟踪调查，结果令人十分吃惊！

　　那3%的人全部成了社会各界的精英，行业领袖；

　　那10%的人都是各专业各领域的成功人士，生活在社会的中上层，事业有成；

　　那60%的人大部分生活在社会中下层，胸无大志，事业平平；

　　那27%的人过得很不如意，工作不稳定，入不敷出，常常抱怨社会，抱怨政府，怨天尤人。

　　在我们的周围这样的人比比皆是，这些人私下里认为自己很聪明，他们满足于混日子，敷衍了事，混水摸鱼，过一天算一天，日复一日年复一年浪费自己 宝贵的青春、生命、大好前程；他不知道自己所做的蹩脚的工作，对老板的损害不及对自身损害的一半。对于老板而言，这可能会是几个美元的损失，但对他自身来说，这却是人格和自尊的丧失，是做人的丧失。

　　回溯历史，我们不难发现，每一个伟大的建树每一项杰出的成就都是由那些志向高远的人所创造的，不论是像爱迪生、福特、贝尔、莱特兄弟这样的发明 家，还是像马丁·路德·金以及从囚徒成为南非总统的纳尔逊·曼德拉这样的社会改革家。他们拒绝接受中庸之道，他们追求卓越，所以他们功成名就，这就是精华法则：最优秀的将会上升到金字塔的顶部。

　　对于年轻人来说，不管现在他多么贫穷或者多么笨拙，只要他有着积极进取的心态和更上一层楼的决心，我们就不应该对他失去信心。对于一个渴望着在 这个世界上立身扬名、成就一番事业的人来说，任何东西都不是他前进的障碍。不管他所处的环境是多么地恶劣，也不管他面临艰难险阻，他总是能通过内心的力量驱动自己，脱颖而出，勇往直前。我们不可能阻挡一个林肯一样、威尔逊一样、或者希尔顿一样的人物的崛起。对于这样的一些人来说，即便是贫穷到买不起书本的 地步，他们依旧可以通过借阅而获得梦寐以求的知识，即使处于卑微的境地，他们也从不放弃梦想。他们即使一次次失败，也从不放弃努力。他们就是拥有“自驱 力”的人。

　　你或许会认为自己太差劲，能成就一番事业的机会和概率微乎其微，但是，问题的关键并不在于你现在的地位是多么地卑微或者从事的工作是多么地微不 足道，只要你有强烈的进取心，只要你不局限于狭小的圈子，只要你渴望着有朝一日成为万众瞩目的人物，只要你希冀着攀登上成功的颠峰并愿意为此付出切实有效的努力，那么任何障碍都阻挡不了你成功的步伐。正如胚芽通过力量的积蓄最终钻出地面一样，竹子需要在地下长四年长到地上然后每年快于一年，你也将通过持之 以恒的努力逐渐地远离平庸，拥有辉煌而壮丽的人生。

　　我们不应该根据人们现在从事的工作来对他进行评判，在确切地了解一个人的理想和抱负之前，无法对一个人轻易地下结论。判断一个人的标准应该是看 他所拥有的抱负和确立的目标。一个年轻人，只要他具备毅力、恒心和信念，他完全有可能成为一个杰出人物。在一个人的日常活动中，我们可以发现某些预示着他的未来的东西。他做事的风格，他对工作的投入程度，他的言行举止——所有的一切都预示着他会拥有什么样的未来。当我们看到一个工作兢兢业业，想方设法地使每一件事都做得尽善尽美，以自己的努力和成就为荣，并在此基础上积极寻求进一步的发展和提高的人时，我相信他总有一天会崭露头角。

　　洛杉矶郊区有个年仅15岁的孩子，拟了一个题为《一生的志愿》的表格，其中包括：

　　“到尼罗河、亚马逊河和刚果河探险；登上珠穆朗玛峰、乞力马扎罗山和麦特荷恩山；驾驭大象、骆驼、鸵鸟和野马；探访马可·波罗和亚历山大一世走 过的路；主演一部像‘人猿泰山’那样的电影；驾驶飞行器起飞降落；读完莎士比亚、柏拉图和亚里士多德的著作；谱一部乐谱；写一本书；游览全世界的每一个国 家；结婚生孩子；参观月球……”

　　他把每一项编了号，共有127个目标。

　　当把梦想庄严地写在纸上之后，他开始循序渐进地实行。

　　16岁那年，他和父亲到佐治亚洲的奥克费诺基大沼泽和佛罗里达州的埃弗洛莱兹探险。
　
　　他按计划逐个地实现了自己的目标， 49岁时，他完成了127个目标中的106个。这个美国人叫约翰·戈达德，获得了一个探险家所能享有的一切荣誉。他集腋成裘、不辞艰苦地努力实现包括游览长城(第40号)及参观月球(第125号)等目标。如果你也能像他一样，从小拥有远大的抱负，有一天，你也会发现自己是那个走得最远的人!

　　当年轻的希尔顿在希尔顿酒店当服务员时，酒店的高层领导已经预测到了，即便希尔顿现在仅仅是一个普通的清洁工，但这个年轻人必定前程无限，因为 他是如此全身心地投入工作，如此地乐观自信，如此强烈地渴望大展宏图。他经手的每一件事都能做到尽善尽美，这些都预示和象征着他未来作为的不可限量。

　　事实证明他的确是做到了这一点。

友元运算符函数只能是一般的类外部友元函数, 而不能是属于某个类的友元成员函数. 如果operator@是A类的成员函数, 同时又是B类的友元, 假设@是m目运算符, 则A类要求operator@只带有n-1个参数. 但同时作为B类的友元, B类要求operator@带有n个参数(因为没有B类的this指针), 由此矛盾.


哇哈哈, 竟然证明C++的语言特性, 这倒是第一次, 值得留念!

// 保持稳定性要求折半查找返回最后相等的关键字的位置或其右边
// high+1: 插入的位置

分析:
由于折半插入排序和直接插入排序相比, 仅减少了关键字比较的次数, 而记录移动次数不变. 其时间复杂度仍为O(n^2).  而且它查找和移动不是在同一个迭代中完成的. 所以只有当n较大时其性能才略优于直接插入排序.