第十步，我是怎样弄清这些的？知道内存，知道内存地址，知道指针是存放内存地址的变量，这么三句话之后，上面的这些不是很自然的理解了吗？

第十一步，有大牛说过，不解决内存泄漏的问题，C++无法做超大型的项目，怎么办？嗯，搜索一下“智能指针”，不过好象我们很少做超大型的项目吧？虽然这里有高手说起500万行以上代码的项目，但做那个的，我觉得和我们几乎是两个世界的人物，或者就是一帮精神病院的家伙。暂时就不要杞人忧天了，发现问题解决问题就是，仿佛一句流行的官话：“发现一起，查处一起”，当然，聪明人马上会想到：怎样才能发现？谁来监督你是否去想办法发现了？怎样查处？谁能知道是否真被查处了？查处了以后会不会马上就复出？中国语言的模糊性，注定了中国程序员的质地。

2、然后是头文件的问题：

对于习惯C#命名空间的人来说，头文件真是很无聊的东西，太古老、太原始，Too simple,some times naive。

我很快弄清了原因，为什么这个是需要的？.net 最终编译之后，保存了元数据，所以你使用一个dll，有反射机制可用。C++没这种东西。

在头文件中声明，在源文件中实现。

声明的意思是告诉编译器，我这里定义了一个类，编译器只需要知道，却不会将这些东西编译到obj或者dll中去。事实上，主要的作用，是编译器知道某个对象分配多少空间，相当于编译器使用的参数。

源文件中include “xx.h”

意思是将头文件全文复制到这里，然后一起交给编译器。

在这里我闹的笑话很简单，就是void CSouGuView::OnButtonHome()

看看这个符号“::”

表示这个类的方法，头文件里要声明，源文件里要实现。

如果没有这个呢？

最初我本能的在源文件中写int xxxx；

当然，不在任何函数内，用起来似乎也比较正常，但总是很奇怪，为什么这里改变了，在那里它也同样改变了。

直到后来出现问题。

甚至你这样自由的在源文件中定义不带“：：”符号的函数

似乎也可以用，但却很奇怪为什么里面的智能感知失效了，用类的成员会出现编译错误。

噢，这种简单的问题是一周后才弄清楚的，不要笑话我，所有人都会碰到的，高手们不会讲解这种问题。

3、代码的坏味道：

极限编程、Scrum这类敏捷流派，耳熟能详的一句话是：“当你复制剪切的时候，就要嗅到代码的坏味道，啊，重构的时机来了。”

看看，两个Command消息函数、两个update的消息函数，是不是都是复制的？为了重用，这里显然要重构一番是吧？对不起，我现在没工夫，就这么对付了。要知道自己的目的，时间花在主要目的上，对于重构也好、对于怎样将代码设计的更柔韧也好，我相信自己比多数人都会强一些----可是我现在在干什么？尽快实现功能，熟练掌握Vc++。重构不需要时间吗？需要的，但这个阶段不能花这种时间。这个小的应用程序，总数不超过15个窗体，几秒钟就能复制粘贴一番，估计到项目结束之后才有空去考虑这个问题。

第二个坏味道，是View类必须知道每个对话框类的名字，当然，这也意味着有多少对话框就要include多少头文件。哇，设计模式发挥作用的地方到了，为每个类提供一个创建实例的方法，然后整个接口？创建一个对话框的基类？我说是吃饱了撑的，有闲的时候再做好不好？每个小时都很重要，你追求的是可扩展性，可是至少要等到你的产品做出来再说吧？或者今后就完全没有扩展的需要呢？或者今后接手的是个菜鸟呢？最优先考虑的肯定是如期完成项目，可扩展性服务的是程序员而不是用户，而大量使用各类设计模式，因为更抽象，所消耗的时间往往是简单实现的数倍以上，是一个工时和5个工时的区别。是否能够分清重点，是智商是否达到及格线的问题，不是技术能力问题。并不是某位高手说“我主要找写库之类的岗位”，那就更高人一等，虽然写库这种词听起来就有些别扭的味道。

做类设计的时候，多一个类可能意味着10%以上的理解难度、开发成本的增长，所以我的目标往往首先是用最少的类实现，只在会影响到实现、或者通用性考虑不足会加大开发成本的情形下，才考虑那些稍稍抽象的东西。我当然也经历过设计模式狂热的短暂阶段，以这种实用主义、直触本质的学习方法，武器显然是不缺乏的。最明显的例子，大家可以看看通达信的股票行情软件，这样以产品吃饭的公司来说，居然存在针对不同证券公司的多种版本，对于开发团队的维护、升级来说，这绝对是一个灾难：不同的公司显然会提出一些各自特色的要求，有些可以拒绝，不能拒绝的往往是公司很关注的部分，这要做好业务分析、精心抽象，并通过通用化的设计，进行单一版本的升级来向所有客户提供同样的功能，是否使用由客户自己决定。这种多样版本并存的情形，源代码管理、开发人员是否永远在公司、自动升级服务器的部署，复杂度和工作量完全是几何级数的增长。至于应用项目，短周期的情形下，则要尽可能回避复杂化的苗头。软件开发首先是生意中的一个环节，在保证交付、稳定运行的前提下，开发和维护成本该怎样控制、如何保证如期交付、如何保证符合合同规定的质量要求，其实是团队要重点平衡拿捏的，这种观念必须贯穿于软件过程的始终。简单的说：你是在工作，不是在研究。

所以按照前面说的，我理直气壮的忽略这些“代码的坏味道”，留待项目结束之后。

再总结一下这短短几行代码，我们逐渐嗅到了些什么东西，当然，谈不上熟悉：

1、消息循环：宏语句，不要探究细节，从字面上理解足够了。

2、类向导：能够用工具就不要手工写了，相当于代码生成器，多用。

3、头文件的问题：理解多数情况下，头文件仅仅是嵌入源代码的“声明部分”。

4、调试、断点设置之类，这个没什么变化。

5、指针：整数，记录某块内存的开始地址。

6、文档视图机制：当作阑尾吧，留着。

7、Ribbon界面的设计：操作问题罢了。

8、对话框的设计、创建类、在视图中显示子对话框。

9、this指针：和C#中一样，this指向是指向类的当前实例的指针，访问类的成员，不是我们习惯的“this.xxx”而是this->xxx，因为是指针么。创建对话框的方法中，this作为参数，意思是将目前的这个view对象的指针，作为参数传递进去。

可能都不是特别的清晰，但不停编码的过程中，不知不觉的你的理解会一步步增强。慢慢来，最终也不会超过一个月的，我们今后会遇到std、stl、各类字符串、unicode问题、多线程问题、Directx Api，发现一起查处一起，这项功能做完，由任务的驱动会逼着我们逐一弄清所有这些语法细节，这样比你主动的去看书强吧？到时候象我这样写几篇博客总结一下，思路能够整理得更为清晰、众多有如牛毛或者过江之鲫的高手们如果肯指出理解上的问题的话，又能够更上层楼，何乐而不为？