//抽象方法
public abstract class Animal
{
public abstract void Sleep();
public abstract void Eat();
}
//虚方法
public class Animal
{
public virtual void Sleep(){}
public virtual void Eat(){}
}

2. 抽象方法只能在抽象类中声明，虚方法不是。其实如果类包含抽象方法，那么该类也是抽象的，也必须声明为抽象的。如：

public class Animal
{
public abstract void Sleep();
public abstract void Eat();
}

编译器会报错：
Main.cs(10): 'VSTest.Animal.Sleep()' is abstract but it is contained in nonabstract class 'VSTest.Animal'
Main.cs(11): 'VSTest.Animal.Eat()' is abstract but it is contained in nonabstract class 'VSTest.Animal'

3. 抽象方法必须在派生类中重写，这一点跟接口类似，虚方法不必。如：

public abstract class Animal
{
public abstract void Sleep();
public abstract void Eat();
}
public class Cat : Animal
{
public override void Sleep()
    {
        Console.WriteLine( "Cat is sleeping" );
    }
// we need implement Animal.Eat() here
}

编译器会报错：Main.cs(14): 'VSTest.Cat' does not implement inherited abstract member 'VSTest.Animal.Eat()'，因为我们没有实现抽象类中所有抽象方法。

可插入协议扩展（Asynchronous Pluggable Protocols）主要基于异步的URL Moniker技术。 IE的URL Moniker在urlmon.dll 动态库中实现的， 有两种处理机制：
1. 根据URL 协议调用外部程序处理
比如telnet: or news: or mailto:，当访问这些url的时候会打开相应的程序来处理。
比如要添加note:协议(Registering an Application to a URL Protocol), 则只要修改注册表
[HKEY_CLASSES_ROOT]
    [note]
        (Default) = "URL:Note Protocol"
        URL Protocol = ""
        [DefaultIcon]
            (Default) = "notepad.exe"
        [shell]
            [open]
                [command]
                    (Default) = "c:\windows\notepad.exe %1"
在IE 中输入 note://xxx.txt 的时候会自动用notepad 打开xxx.txt 文件

2. 根据URL 协议调用类对象来处理
可以根据URL 协议或者MIME type 注册不同的处理对象
有两种方式：
a) 通过在注册表将URL 协议与COM 对象关联
主要在注册表中的
HKEY_CLASSES_ROOT\PROTOCOLS\Handler # URL 协议
HKEY_CLASSES_ROOT\PROTOCOLS\Filter # Mime Filter

b) 通过临时注册类对象将URL 协议与其关联
// 注册
CComPtr<IInternetSession> spSession;
CComPtr<IClassFactory>   spCFHTTP;
HRESULT hr = CoInternetGetSession(0, &spSession, 0);
hr = FilterFactory::CreateInstance(CLSID_HttpProtocol, &spCFHTTP);
hr = spSession->RegisterNameSpace(spCFHTTP, CLSID_NULL, L"http", 0, 0, 0);

// 反注册
spSession->UnregisterNameSpace(spCFHTTP, L"http");

3. FilterFactory 的实现可以参考
Asynchronous Pluggable Protocol Implementation with ATL
http://www.codeguru.com/cpp/com-tech/atl/misc/article.php/c37/
Internet Explorer下载文件的终极过滤
http://blog.csdn.net/111222/archive/2002/02/09/7255.aspx

通过Mime filter技术对网页源码进行过滤（监视下载文件）
http://blog.csdn.net/lion_wing/archive/2006/06/27/839134.aspx
HTML代码过滤技术
http://blog.csdn.net/lion_wing/articles/534716.aspx

About Asynchronous Pluggable Protocols （MSDN）
Internet Explorer 编程简述（九）在自己的浏览器中嵌入Google工具条
http://blog.csdn.net/CathyEagle/archive/2005/12/12/550698.aspx
放1000分，高手进来动手试试：如何提取AJAX里的HTML内容？
http://topic.csdn.net/t/20061214/12/5230161.html
这里主要通过监视IE 的下载从而保存Google Map 的地图数据文件.  通过监视http & text/html & application/javascript 的内容来获取图片文件URL 和 信息.. :)

原文链接：http://www.51testing.com/?103489/action_viewspace_itemid_70804.html

之前一个朋友问起我，说做了那么多年开发，谈谈有些项目为何失败。朋友说项目失败很大的原因是在合同问题，合同没有很好的列出项目范围。其实，合同的范围只是一般的范围，详细内容应该不属于合同的一部分。所以我觉得项目最大的问题还是需求没做好。需求没有做好，主要表现在以下几个方面：

一、需求采集与分析

  1、需求采集分析时，没有从完整的业务流程出发，容易关注主要业务需求，而造成次要业务需求块的遗漏。

   之前检查了我们公司一个重要项目的需求做得咋样，光看需求提问单，就发现大部分问题是关于功能需求的。而问起业务需求时，他们说都很清楚了，但问起业务上细节处理时，大家都恍然大悟：“哦，这里需要再问下客户...”。

  2、开发人员除了关注采集功能需求、外部接口需求、性能需求和一般的标准需求外，往往容易忽略系统领域的背景、操作环境需求、用户特殊需求（例如用户熟练使用的工具与方法）等。

二、需求定义与确认

   需求规格说明书是将人们思想中的概念和目标转换成正式的文档，在这个过程中，很容易产生错误，例如表达不完整，不正确的事实，不一致或模糊的需求等。因此，一定要正确详细的进行需求定义与验证，确保规格化的内容确实是用户所需求的东西。

三、需求变更

  需求变更管理有两个方面，一是与客户就怎样变更达成一致，一个是进行变更流程控制活动。在这两个方面都容易出错。

  1、与客户达成一致方面，需要让客户意识到变更对项目影响的后果，要技巧性+友好性的将变更加入到协商条款中。在评估需求变更达到一定的影响时，要试图协商控制变更，以保证在需求变更下，项目可以继续成功。

  2、变更流程控制活动，包括怎么进行变更请求，怎么进行变更批准等过程控制，还要考虑为处理变更估计留出时间等等方面的问题。这方面不遵循过程控制流程来走，很容易导致花大功夫补救的后果。

  我们公司已经对变更没有做很好的控制，就吃了很多亏。我们项目组是驻客户所在地办公，开发人员经常接到客户电话来提出一些功能性的小变更，考虑到是小变更，又受“客户是上帝、提高客户满意度”等思想的影响，也就痛快答应，甚至当场修改程序发布。客户是高兴了，短期来看，效率高，而且还与客户打好关系。可长期来看，上此以往，这种行为就变成“没有跟客户计算成本”的花费，这还是小事，更严重的问题是，这种没有经过整体评估、影响分析、风险识别与分析的行为，有可能改了东家，拆坏了西家，到最后要花费更大的财力去弥补，吃力不讨好，更甚的后果是因为这些漏洞，迟迟拖延项目验收时间，从而导致项目失败。

[二．策略性的作业方式]
8. 错虫愈晚清除，时间花得愈多。毕竟，您得知道程序是怎么写的，才能判断那里出了错虫；刚写完的程序记忆犹新，一年前写的程序可能早就忘了。
9. 在开发的过程就立即除虫，可以让您早些学到经验，然后就不会再犯同样的错误；相反地，如果到了项目后期才发现，您可能已经犯过多次同样的错误而不自知。
10. 发现错虫而立即除错是一种缓冲器，提醒那些讲求快速而不够谨慎的程序设计师，以后多加小心。如果您坚持错虫全都清除了才能开发新的功能，就可以防止所有的程序处于半完成状态，因为错虫太多而使项目延误乃至无法推出；相反地，如果您允许错虫的存在，等于是埋下了项目失控的地雷，最后看似完成的项目，其实已经失控。
11. 若能保持没有任何错虫，您就能比较准确估出项目的完成时间。不必猜测3 2项功能和1 742个错虫共要花费多少时间，只要估算3 2项功能的工作时间就行了。更重要的时，万一到时候有些功能做不完，您可以做多少算多少，因为软件一直保持在无错误状态。
12. 不要把策略性工作方式当作训练的教条，应该向组员解释这些工作方式的内涵与用意。
13. 提出精确详尽的问题，可以引导出真正有效的策略性工作方式，帮助项目目标顺利完成。
14. 策略不是死的定律，要把它当作指导原则来活用。大部分的时候都应该遵循，但也有例外的时候。

[三．保持进度]
15. 定期暂停手边的工作，然后往前思考，随时做必要的修正，以避免未来的大障碍。
16. 有什么事情是我今天能做，而且可以帮助项目在未来几个月内顺利进行的？
17. 不要浪费时间在错误的问题上，一定要先确定真正的问题在哪里，然后才去改正它。
18. 人们开口要求的东西未必是他真正想要的。处理他的要求之前，请务必确定他究竟想要做什么。
19. 绝对不要答应别人自己做不到的事情，这样对双方都有益无害。
20. 不要为了讨好别人而伤害双方的工作进程，您永远要根据自己的目标，做适当的决策。
21. 是您在为项目负责。不要让任何人的建议阻碍项目的进行，包括上级的建议。
22. 天下没有真正免费的软件
23. 应该开发策略上具有重要性的功能，而不是把媒体的评比项目都做齐全。
24. 软件产品的开发，不能只为了有趣、挑战性，或是够有个性够令人眩目。
25. 不要把时间浪费在无法改善产品的工作上，即使这么做在将来会有潜在的利益，也要与现在投入的时间成本做个衡量。

[四．走向极端的狂热]
26. 确定您所要求的报告真的值得属下暂停工作，花那么多时间去写。
27. 利用项目检查报告来改进软件开发的工作程序。为了使报告发生作用，报告中必须确实描述我们这次解决问题的每一个详细步骤，以及将来应该如何运用这项新发现。
28. 请注意定期会议的价值，确定它值得每个人放下手上的工作。
29. 召开任何会议之前，请确定本次会议的目的是什么，达成这个目的的条件是什么，然后，务必达到开会的目的。
30. 试着排除不必要的后续工作。

[五．进度狂]
31. 不要利用进程表来驱使项目的进行，这对小组的士气伤害太大了。
32. 让日程表维持适度的紧迫，但又是可以做到的，好让组员振奋、不松懈，专心致力于项目的推进。
33. 绝对不要草率定出不可能的期限，导致组员为了赶进度而损害产品的质量。
34. 把长期的大项目，分成几个完整而独立的小项目，各小项目必须有一个主题。
35. 为了保持创意的活力和团队士气，必须让每一个小项目都有令人兴奋的结果。
36. 产品的质量远比遵守期限重要.

[六．学无止境]
37. 不要让程序设计师的学习停滞不前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺样样精通的组员。
38. 训练新进程序设计师时，先培养他对整个公司所有项目都有价值的技术，然后才培养本项目独有的技术。
39. 不要舍不得放您最优秀的程序设计师到别的项目去。如果他在您的项目已经没有新的东西可学，为了公司和他个人的前途，您应该把他推荐到别的项目，让他的成长永不间断。
40. 确定每位组员、每两个月都有一项技术上进步。
41. 一发现某处需要改进，就立即采取更正的行动。
42.不要用年终考评来订立学习目标，要利用年终考评来记录个人的成长。
43. 绝对不要让组员一直做同样的工作，这样是限制了他的学习，使他停滞在原来的领
域。一旦程序设计师精通了某一个领域，就让他换别的领域做做看，永远让他们学习新的技术。
44. 各种技术的用途范围有所不同，有的技术在一般的项目都用得上，有的技术只有在特定性质的项目才用得上。当您训练您的组员时，必须让他们的技术能在公司发挥最大的用处，最好的办法就是，把应用范围最广的技术放在训练的最前期，应用范围最小的技术放在最后训练。
45. 优秀的程序设计师是项目经理最需要的，所以经理们通常舍不得让自己手下功力最强的人到别组去，但是如果这位第一高手在本组内再也没有新东西可学时，经理就应该让他到别的项目去，一方面他个人可以重新开始另一次的成长，一方面让接替他的人学着承担重要的工作，最后公司的平均程序技术水准因而提升，对大家都很有好处。
46. 为了确保每位程序设计师的技术都在稳定地进步，一定要让每个人有个努力的目标，最好的方法是把个人的成长和项目每两个月的阶段性目标相结合，这样一年就有至少六次的进步了。假定一位组员在公司待了五年，那么他就学了3 0种新技术、或是读了3 0本好书、或是1 5项技术加1 5本书，对他的工作能力影响多大啊。
47. 最好的成长目标是出于当时的需要。如果您发现有位组员工作缺乏效率，或总是在犯同样的错误，最好抓住机会立即为他立一个目标，并且要求他立刻开始改进。这种当时设立的目标让人印象深刻，又是马上寻求改善，效果通常会非常好。比起年终考评那种模模糊糊的建议，更能引起程序设计师的重视。

[七．态度问题]
48. 要让每一位程序设计师都明白，写出零错误程序是很不容易的，所以应该多花功夫用各种方法做最彻底的测试。
49. 纠正程序设计师以为加除错码会花太多时间的观念，应该训练程序设计师第一个反应是考虑加上除错码是否有道理，第二是考虑加除错码是否符合项目的目标与工作的优先级。
50. 当某人说“某件事不可能做到”时，他往往是错的。
51. 不要让凡事不能的态度阻碍了创新。
52. 使用者和程序的撰写者一样关心速度和品质的问题。
53. 不要让程序设计师以为使用者并不在乎软件的质量。
54. 不要给使用者次品，宁愿延期交货，务必追求质量完美。
55. 程序设计师必须经常以使用者的观点来看自己写的程序，程序设计师必须能体会使用者的感受。
56. 在包装盒里的每一件东西，都是产品的一部分。
57. 将程序的重用性当作优先考虑的目标之一，否则程序设计师将经常做重复的工作。
58. 充分利用现有资源或创造新资源，以便从每一项工作中获得更大的价值。程序代码的再利用，就是很好的例子，当然，还有其他的地方可以运用“杠杆原理”。
59. 如果您创造了一项资源，并且让别人知道，那么总有一天会派上用场。
60. 从您的每件工作中创造最大的资源，不管是利用现有的杠杆，或是创造新的杠杆。
61. 小心那种“太难了”、“太花时间”或是“太麻烦”的反射性反应。当您遇到别人有这种反应，请先问自己他有没有认真思考过这件事的重要性、以及是否符合项目目标，如果您认为他其实未经深思熟虑，只是直觉的反应，那您就应该把您的想法告诉他，请他重新评估，也许就会有公平的答案。
62. 人们遇到经验范围之外的事情，多少有恐惧感，就会认为“这完全不可能”而强烈反对。试着消除这种习惯性的反应，设法给组员灌输“只要花时间想想看，大部分的事情都做得到”的观念。您不妨以这个问题来对付那种“凡事不能”的态度：“我了解这是做不到的，但是‘如果’做得到，那你会怎么做？”然后您就会发现惊人的转变，您马上就会听到组员七嘴八舌地说应该这样做、那样做，说的是他们刚刚坚持做不到的事情。这个“如果”把他们带离直觉的反应，带到全新的思考模式，这才是他们应该做的。
63. 把使用者当作什么都不懂的外行人，是非常不好的观念。每当您发现有人表露出这种心理，一定要立即纠正，提醒他们使用者才是真正受产品好坏影响最深的人，他们和程序设计师一样关心软件的执行速度和质量。
64. 杠杆原理是您最有用的观念，找到您工作中的杠杆，您可以为小组、项目、公司、甚至软件业创造无可限量的价值。无论如何，尽量利用资源并创造资源，这个原则是绝对错不了的。在您写程序的时候注意程序代码的共享性、训练组员的时候注意到他对公司的价值，即使是像函数命名这种小事，都有杠杆的存在。不管做任何事，都要想到“善用资源”，为未来做好准备。

[八．沉船的感觉]
65. 如果进度发生落后，那表示有个地方出错了。您应该找出问题，并加以解决，不要一味要求组员加班，在问题没有解决之前，加班是没有用的。
66. 别误信加班等于增加生产能力，长期的加班只会伤害生产能力，对项目没有帮助。
67. 周末是属于组员私人的时间，不是公司的。公司不应该以打败竞争对手为理由，要求员工周末加班。
68. 强调思考的重要性，而不是长时间工作。
69. 训练开发小组懂得在正常工作时间内掌握好工作的效率，不要让他们超时工作，因为超时工作只是浪费时间的假面具。
70. 与程序设计师共同研拟出一份每日活动的时间表，把无法预期的临时公务变成固定时间处理的事情，并且把程序开发的工作放在最优先的地位，不要让其他次要的事情干扰到写程序。
71. 经常加班就是项目出问题的明显信号，也许是因为主管的观念错误或是目标不够清楚，不论是什么原因，项目经理绝对不能忽视这种现象，要对这个问题正确处理，项目经理必须协助组员在每周4 0小时的工作时间里，把事情做得更有效率。
72. 我经常听到高层主管称赞组员每天为公司工作很长的时间：“您对公司的贡献值得嘉奖，做得很好！”这绝对是错误的信息，员工应该是因为工作做得好而受到称赞，而不是因为在办公室待得久，管理者不该把“生产效率”和“工作时间”混为一谈，有的人也许可以用更少的时间，完成两倍的工作呢。
73. 为了让组员把办公时间用在正确的地方，并提高部门的工作效率，项目经理不但要为他们排除任何不必要的会议、报告和杂事，还要协助他们好好运用宝贵的上班时间。您应该协助组员安排适当的每日活动表，用一些小技巧，让组员有长段又不受干扰的时间，适合进行开发工作。
74. 如果您关心组员的生活，就不要让他们把全部的时间都投入在工作。每天只要确定他们卖力工作了八小时，就可以把他们赶出办公室了，当然这样做也许会有老板看不顺眼，但是如果您像我一样相信均衡、健康的生活是一切创意的原动力，就坚持这份理念吧！
75. 每周工作4 0小时并不是金科玉律，只不过是美国的传统，而软件开发项目大都以此为前提编定日程表。所以如果一个项目需要程序设计师每周工作40 小时以上才能赶上进度，就表示有问题，也许是日程表定得太乐观，也许是程序设计师需要再训练。不管怎么说，这个问题一定要认真解决，绝对不应该让程序设计师加班来弥补这个漏洞。

一、全心投入工作（work harder at what you do）：当你工作时，一定要全心投入，不要浪费时间，不要把工作场所当成社交场合。光这个秘诀，如果你能长期实践，就能使你的生产力加倍。

二、工作步调快（work faster）：养成一种紧迫感，一次专心做一件事，并且用最快的速度完成，之后，立刻进入下一件工作。养成这习惯后，你会惊讶地发现，一天所能完成的工作量居然是如此地惊人。

三、专注于高附加值的工作（work on higher-value activities）：你要记住工作时数的多寡不见得与工作成果成正比。精明的老板或是上司关心的是你的工作数量及工作品质，工作时数并非重点。因此聪明的员工，会想办法找出对达成工作目标及绩效标准有帮助的活动，然后投入最多时间与心力在这些事情上面。投入的时间愈多，每分钟的生产力就愈高，工作绩效也就提高，自然赢得老板及上司的赏识与重用，加薪与升迁在望。

四、熟练工作（do things you are better at）：你找出最有价值的工作项目后，接着要想办法，通过不断学习、应用、练习，熟练所有工作流程与技巧，累积工作经验（一句话解决KNOW HOW的问题）。你的工作愈纯熟，工作所需的时间就愈短；你的技能愈熟练，生产力就提升得愈快。

五、集中处理（bunch your tasks）：一个有技巧的工作人，会把许多性质相近的工作或是活动，例如，收发E-MAIL、写信、填写工作报表、填写备忘录等等，集中在同一个时段来处理，这样会比一件一件分开在不同时段处理，节省一半以上的时间，同时也能提高效率与效能。

六、简化工作（simplify your work）：尽量简化工作流程，将许多分开的工作步骤加以整合，变成单一任务，以减少工作的复杂度，另外，运用授权或是外包的方式，避免把时间花费在低价值的工作上。

七、比别人工作时间长一些（work longer hours）：早一点起床，早点去上班，避开交通高峰；中午晚一点出去用餐，继续工作，避开排队用餐的人潮；晚上稍微留晚一些，直到交通高峰时间已过，再下班回家。如此一天可以比一般人多出2至3个小时的工作时间，而且不会影响正常的生活步调。善用这些多出来的时间，可以使你的生产力加倍，进而使你的收入加倍。一个成功的人，通常是一个行动派的人，一旦懂得提升生产力的方法，就会将这7个小秘诀，默记在心，不断地应用、练习，直到成为工作、生活的习惯为止。只要养成这个习惯，你的生产力一定会提高，收入也会加倍。

template<typename T>
struct _UuidTraits
{
};

这个类没有任何实现，uuid数据将存储于其特化版本，看以下的代码

class ClassA;
template<>
_UuidTraits<ClassA>
{
    static const char * uuid = "ClassA";
};
class ClassA
{
    //any code of ClassA
};

现在我们可以通过 _UuidTraits<TheClass>::uuid 来取类ClassA的uuid来，方便使用我们定义一个宏
#define __uuidof(x) (_UuidTraits<x>::uuid)
但这样只实现了ClassA的uuid，如果为每个类都写一个_UuidTraits的特化版本有点累，但我们可以用宏来简化

#define DEFINE_UUID(x, uuidofx) \
class x; \
template<> \
_UuidTraits<x> \
{ \
static const char * uuid = #uuidofx; \
}; \

这样我们就可以方便的为类定义uuid了，比如：

DEFINE_UUID(ClassB,  ClassB) 
class ClassB
{
//any code of ClassB
};

OK，现在试试__uuidof(ClassB)，应该返回字符串"ClassB"了。
还有一点要说明的是，为了能兼容UNICODE，可以定义两个版本的DEFINE_UUID：

#ifdef UNICODE
#define DEFINE_UUID(x, uuidofx) \
class x; \
template<> \
_UuidTraits<x> \
{ \
static const wchar_t * uuid = L#uuidofx; \
}; \
#else
#define DEFINE_UUID(x, uuidofx) \
class x; \
template<> \
_UuidTraits<x> \
{ \
static const char * uuid = #uuidofx; \
}; \
#endif

这样在使用UNICODE字符编码编译时，__uuidof返回的就是unicode字符串了

一个由C/C++编译的程序占用的内存分为以下几个部分:

1. 栈区（stack）—由编译器自动分配释放，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。
2. 堆区（heap）—一般由程序员分配释放，若程序员不释放，程序结束时可能由OS回收。注意它与数据结构中的堆是两回事，分配方式倒是类似于链表，呵呵。
3. 全局区（静态区）（static）—全局变量和静态变量的存储是放在一块的，初始化的全局变量和静态变量在一块区域，未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。程序结束后由系统释放。
4. 文字常量区—常量字符串就是放在这里的。程序结束后由系统释放。
5. 程序代码区—存放函数体的二进制代码。

二、例子程序

这是一个前辈写的，非常详细。

//main.cpp
int a=0;    //全局初始化区
char *p1;   //全局未初始化区
main()
{
  int b;栈
  char s[]="abc";   //栈
  char *p2;         //栈
  char *p3="123456";   //123456\0在常量区，p3在栈上。
  static int c=0；   //全局（静态）初始化区
  p1 = (char*)malloc(10);
  p2 = (char*)malloc(20);   //分配得来得10和20字节的区域就在堆区。
  strcpy(p1,"123456");   //123456\0放在常量区，编译器可能会将它与p3所向"123456"优化成一个地方。
}

三、堆和栈的理论知识

2.1 申请方式
stack:
       由系统自动分配。例如，声明在函数中一个局部变量int b;系统自动在栈中为b开辟空间
heap:
       需要程序员自己申请，并指明大小，在c中malloc函数
               如p1=(char*)malloc(10);
               在C++中用new运算符
               如p2=(char*)malloc(10);
               但是注意p1、p2本身是在栈中的。

2.2 申请后系统的响应
栈：只要栈的剩余空间大于所申请空间，系统将为程序提供内存，否则将报异常提示栈
        溢出。
堆：首先应该知道操作系统有一个记录空闲内存地址的链表，当系统收到程序的申请时，
       会遍历该链表，寻找第一个空间大于所申请空间的堆结点，然后将该结点从空闲结点
       链表中删除，并将该结点的空间分配给程序，另外，对于

大多数系统，会在这块内存空间中的首地址处记录本次分配的大小，这样，代码中的delete语句才能正确的释放本内存空间。另外，由于找到的堆结点的大小不一定正好等于申请的大小，系统会自动的将多余的那部分重新放入空闲链表中。

2.3 申请大小的限制
栈：在Windows下,栈是向低地址扩展的数据结构，是一块连续的内存的区域。这句话的
        意思是栈顶的地址和栈的最大容量是系统预先规定好的，在WINDOWS下，栈的大
        小是2M（也有的说是1M，总之是一个编译时就确定的常数），如果申请的空间超
        过栈的剩余空间时，将提示overflow。因此，能从栈获得的空间较小。
堆：堆是向高地址扩展的数据结构，是不连续的内存区域。这是由于系统是用链表来存
        储的空闲内存地址的，自然是不连续的，而链表的遍历方向是由低地址向高地址。
        堆的大小受限于计算机系统中有效的虚拟内存。由此可见，堆获得的空间比较灵活，
       也比较大。

2.4申请效率的比较
栈:由系统自动分配，速度较快。但程序员是无法控制的。
堆:是由new分配的内存，一般速度比较慢，而且容易产生内存碎片,不过用起来最方便.
     另外，在WINDOWS下，最好的方式是用Virtual Alloc分配内存，他不是在堆，也不是在 
     栈,而是直接在进程的地址空间中保留一块内存，虽然用起来最不方便。但是速度快，
     也最灵活。

2.5 堆和栈中的存储内容
栈：在函数调用时，第一个进栈的是主函数中后的下一条指令（函数调用语句的下一条可 
        执行语句）的地址，然后是函数的各个参数，在大多数的C编译器中，参数是由右向左
       入栈的，然后是函数中的局部变量。注意静态变量是不入栈的。当本次函数调用结束
       后，局部变量先出栈，然后是参数，最后栈顶指针指向最开始存的地址，也就是主函
       数中的下一条指令，程序由该点继续运行。
堆：一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容由程序员安排。

2.6 存取效率的比较

char s1[]="aaaaaaaaaaaaaaa";
char *s2="bbbbbbbbbbbbbbbbb";
aaaaaaaaaaa是在运行时刻赋值的；
而bbbbbbbbbbb是在编译时就确定的；
但是，在以后的存取中，在栈上的数组比指针所指向的字符串(例如堆)快。
比如：
#include
voidmain()
{
char a=1;
char c[]="1234567890";
char *p="1234567890";
a = c[1];
a = p[1];
return;
}
对应的汇编代码
10:a=c[1];
004010678A4DF1movcl,byteptr[ebp-0Fh]
0040106A884DFCmovbyteptr[ebp-4],cl
11:a=p[1];
0040106D8B55ECmovedx,dwordptr[ebp-14h]
004010708A4201moval,byteptr[edx+1]
004010738845FCmovbyteptr[ebp-4],al
第一种在读取时直接就把字符串中的元素读到寄存器cl中，而第二种则要先把指针值读到edx中，在根据edx读取字符，显然慢了。

2.7 小结
堆和栈的区别可以用如下的比喻来看出：
使用栈就象我们去饭馆里吃饭，只管点菜（发出申请）、付钱、和吃（使用），吃饱了就走，不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作，他的好处是快捷，但是自由度小。使用堆就象是自己动手做喜欢吃的菜肴，比较麻烦，但是比较符合自己的口味，而且自由度大。

大概看了一下，似乎就是对WTL的一些东西的封装，并添加了可视化向导对话框，使用起来更方便，上手起来比较容易。但是我现在还没搞清楚他整个的目录结构。

先记录下来，有空的时候研究研究。:)