1) 默认是可以忽略的，因为调用函数时可以不处理其返回值，从而错误处理要依赖于程序员的主动性，而不是程序机制的要求；

2) 不能跨作用域传送，必须逐层向上转发，即使中间没有对错误码进行重新定义；
 

使用异常可以解决解决这两个问题：

1) 异常默认是不可忽略的，抛出的异常必须捕获，否则就会报错；

2) 异常可以跨作用域传送，从而错误的发现和处理被很好地分离开来；
 

2. 异常和断言的区别：
 

异常被捕获后可以不作处理，程序从捕获位置继续执行。而断言是完全无法忽略的，程序在断言失败处立即终止。因此断言通常用于调试版本，用来发现程序中的逻辑错误。虽然异常也能起到这样的作用，但是不应该用异常代替断言：
1) 如果发现了逻辑错误，必须修改程序，而不可能在程序中进行处理和恢复，所以不需要向外传送，没有必要使用异常。
2) 使用断言的开销比异常小得多，而且断言可以从发布版中完全去除。
 

异常用于处理正确程序中的运行期问题(比如内存分配失败，窗口创建失败，线程创建失败，打开文件失败)，以尽可能恢复，而不是终止程序。对于运行异常，使用断言是非常不合适的，理由很显然：
1) 断言在发布版不起作用；
2) 断言的处理方式不够友好；
3) 运行异常不是程序错误，没有必要报告源代码出错位置；



参考资料：

1.《C++编程规范-101条规则、准则与最佳实践》/Herb Sutter，Andrei Alexandrescu 著 刘基诚 译 人民邮电出版社
2.《C++程序设计语言》/Bjarne Stroustrup 著 裘宗燕 译 机械工业出版社
3.《C与C++中的异常处理》/Robert Schmidt 著 无情 译 http://download.pchome.net/development/reference/11135.html

为一类产品 ( 一个抽象产品及其所有具体产品 ) 提供一个工厂，该类的每一种具体产品由工厂中的一个方法创建。种种做法的缺点是不易增加新的具体产品，每增加一个具体产品，工厂中就要增加一个方法，这意味着工厂的所有使用者都要重新编译。可以用参数化的方法来改进，工厂只提供一个接受参数的创建函数，参数的取值标志了某种具体产品，在创建函数中对参数进行判断，根据不同的参数值创建不同的具体产品并返回。这就减小了增加具体产品的代价，每增加一种具体产品时只要修改工厂的创建函数的实现即可。

原来是用工厂的不同方法创建不同的具体对象，现在是用同一个方法的不同参数创建不同的具体对象。还可以用抽象工厂的不同派生类来创建不同的具体对象，这种做法比较笨重.

Abstract Factory-可替换的工厂：

见参考资料1


参考资料：

1.《设计模式-可复用面向对象软件的基础》/Erich Gamma等著，李英军等译 机械工业出版社
2.《敏捷软件开发-原则，模式与实践》/Robert C.Martin著 邓辉译  清华大学出版社

MFC的文档/视图结构(Document/View architecture)是MVC模式的一种变体，下面讨论它是怎样实现的。

文档/视图结构没有体现业务逻辑和视图的分离，但是将响应策略和视图区分开来。它主要包含四种对象：

1. 文档
2. 视图
3. 视图框架窗口
4. 文档模板

这里的视图框架窗口定义了视图对用户输入的响应方式，而文档模板用来管理前三种对象的组合。文档，视图，视图框架窗口三者是对应的，从而构成一个三元组。一个应用程序可能需要多个这样的三元组，以实现文档的多视图，所以引入文档模板来表示该三元组。因为程序中可能使用多个文档模板，MFC用一个文档管理者对象来管理它们。

在MFC中，应用程序和主框架窗口是用来封装底层机制的对象，文档，视图，视图框架窗口和文档模板是用来构架文档/视图结构的对象。应用程序通过文档管理者来使用文档/视图结构。

如果要给文档增加一种视图，只需要增加一个文档模板；如果要改变一种视图的响应策略，只要改变对应文档模板中的视图框架窗口。

<未完待续>


参考资料：

1.《设计模式-可复用面向对象软件的基础》/Erich Gamma等著，李英军等译 机械工业出版社
2.《Java与模式》/阎宏 电子工业出版社
3.  模型-视图-控制器 ( MSDN > 技术资源库 > 体系结构 > 使用 Microsoft .NET 的企业解决方案模式 >第3章 Web 表示模式)
4. 《Java设计：对象，UML和过程》/Kirk Knoernschild 著，罗英伟等译 人民邮电出版社
5. 《计算机网络与因特网》/D.E.Comer 著 徐良贤等译 机械工业出版社
6.《深入解析MFC》/中国电力出版社
7.《VC技术内幕》第5版 / 希望电子出版社

这里面涉及到一些程序和数据，它们存放在不同的地方，在不同阶段运行。第一段程序MBR，它的数据是DPT，它们存放在磁盘的主引导扇区。第二段程序是系统引导记录，存放在系统所在分区的引导扇区。第三段程序是系统启动文件，存放在系统所在分区系统安装目录中。这三段程序像接力跑一样，前一段程序的工作就是加载后一段程序，并把控制交给它。 引导记录和启动文件随操作系统而不同， 是在安装时形成的，每个系统的安装程序都把其引导记录写入安装分区的引导扇区，而启动文件是系统的一部分。

上面的引导过程有一个基本缺陷，就是只能引导一个系统，并且只能引导装在第一活动分区的系统。

如果一个操作系统不在活动分区，那么该系统要被引导有三种办法，改写MBR，改写第一活动分区引导记录，或把所在分区设为第一活动分区。最后一种做法是不方便的，系统通常会改写前两段引导程序，那么它在解决自身引导问题的同时，也不能破坏其他系统的引导，这就引出了多系统地引导问题。常见的做法是系统提供一个启动管理器接管引导过程。启动管理器能够获得机器上多个系统的引导记录，从而可以根据用户选择启动不同的系统。系统在安装时改写磁盘第一活动分区的引导记录，使启动管理器被作为第三段程序加载。

如果启动管理器能够知道机器上每个系统所在的分区，就能获得该系统的引导记录，从而可以引导该系统。但实际上，启动管理器所属系统的引导记录是不能再次被加载的，必须特殊对待。同一系列的系统，也可能有类似的问题。所以启动管理器可能要了解机器上每个系统具体如何启动，相应进行引导。这样只有让高版本的系统提供启动管理器，因为低版本的启动管理器无法启动高版本系统。2000/XP的启动管理器是OS Loader。它对98和2000/XP的引导就是不同的，对98是加载98引导记录的镜像文件，对2000/XP是加载HAL.DLL等文件。OS Loader在引导多系统时，对于windows系列的引导有特殊性，必须向下兼容。

OS Loader的载体是ntldr文件，它运行时还会读取一个配置文件boot.ini，两个文件都存放在磁盘第一活动分区根目录。boot.ini记录了每个系统所在的分区，每个版本的windows在安装时都会在boot.ini中填写有关自身的一项。2000/XP在安装时都会更新OS Loader和重写第一活动分区的引导记录，后安装者的两个程序才会被保留。如果后装2000，由于前述的OS Loader版本问题，就可能无法引导XP。

动态创建就是创建某种类型的对象，具体类型在运行时确定，编译时可能不知道。比如运行时用户输入一个类型名称，如果该类型是程序类型体系中的一员，则程序中将能够创建该类型的对象。下面的代码是使用MFC动态创建机制的一个简化的例子：

CRuntimeClass* g_pFirstClass;
void func()
{
     char szClassName[64];
     CRuntimeClass* pClass;
     CObject* pObject;
    
     cout << "enter a class name...  ";
     cin >> szClassName;
    
     for (pClass = g_pFirstClass; pClass != NULL; pClass = pClass->m_pNextClass)
     {
          if (strcmp(szClassName, pClass->m_lpszClassName) == 0)
              pObject = pClass->CreateObject();
     }
}

实现动态创建的思路是把动态的类型名称与程序类型体系中的每一个进行比较，与某个类型吻合时让该类型创建自身的对象。这样，支持动态创建的类库中的每一个类都要额外实现一些功能，即判别一个名称是否与自身相符，以及创建自身的对象。

判别一个名称是否与自身相符，这是运行时类识别的内容，所以MFC动态创建是在RTCI基础上实现的。

RTCI是一个对象能够判定自己是否属于某种类型，该类型的名称在运行时确定，编译时可能不知道。从下面的例子很容易理解RTCI，

void Func()
{
     char szClassName[64];
     CDocument* pDoc = new CDocument;
    
     cout << "enter a class name...  ";
     cin >> szClassName;
    
     cout << pDoc->IsKindOf(szClassName); //是返回1，否返回0
}

有一点需要说明的是，因为CDocument派生于CObject，所以IsKindOf对于CObject也要返回1。因为我们是从动态创建出发的，所以如果是这样可能会有一点背离初衷。但是RTCI明显和动态创建有密切联系，RTCI也可能有单独的价值，所以先把RTCI实现起来。

实现RTCI的思路是让每一个类记录自身的类型信息，并提供IsKindOf(char*)函数进行所给类型与自身类型的比较，而且还要能访问基类的类型信息，进行比较，一直到根类。所以记录的类型信息要按继承关系连起来，每个类的IsKindOf()还要调用基类的IsKindOf()。MFC把要记录的类型信息抽取到一个CRuntimeClass结构体中，每个类中加入一个CRuntimeClass成员即可。

现在回到动态创建，在RTCI建立的数据结构基础上将可实现它。动态创建从不同于IsKindOf()的角度使用这一数据结构，它要遍历所有类型的CRuntimeClass。那么仅仅有继承关系的类的CRuntimeClass相连还不够，要把所有类的CRuntimeClass连成一个链表。其实动态创建并不关心类间的继承关系，它平等看待每个类。现在以CRuntimeClass为结点构成一个纵横两个方向的链表，IsKindOf()和动态创建分别使用它不同的侧面。

序列化的概念是在文件中存储对象信息，并能根据它恢复对象。对于文档视图结构的软件，用户需要保存所编辑的文档和打开已编辑的文档，这正是序列化的应用，所以序列化是非常重要的一种特性。在序列化恢复对象时，就可以用到动态创建。

使用MFC序列化的例子如下，

void CMyDocument::Serialize(CArichive &ar)
{
    if (ar.IsStoring())
    {
        ar << m_pMyClass; //CMyClass m_pMyClass;
    }
    else
    {
        ar >> m_pMyClass;
    }
}

一个支持序列化的类提供Serialize(CArchive &)函数，重载<<和>>操作。注意两者是不同的，在上例中，CMyDocument类的信息并不被序列化，而CMyClass类的信息被序列化。实际上一个序列化类的<<和>>操作，其不涉及类信息的部分是调用Serialize()完成的，它必须同时实现这两者。

按照MFC的要求，需要在支持序列化的类定义中使用DECLARE_SERIAL宏，在类实现中使用IMPLEMENT_SERIAL宏。我们看一下这两个宏实现了什么，

#define DECLARE_SERIAL(class_name) \
 _DECLARE_DYNCREATE(class_name) \
 AFX_API friend CArchive& AFXAPI operator>>(CArchive& ar, class_name* &pOb);

#define IMPLEMENT_SERIAL(class_name, base_class_name, wSchema) \
 CObject* PASCAL class_name::CreateObject() \
  { return new class_name; } \
 _IMPLEMENT_RUNTIMECLASS(class_name, base_class_name, wSchema, \
  class_name::CreateObject) \
 AFX_CLASSINIT _init_##class_name(RUNTIME_CLASS(class_name)); \
 CArchive& AFXAPI operator>>(CArchive& ar, class_name* &pOb) \
  { pOb = (class_name*) ar.ReadObject(RUNTIME_CLASS(class_name)); \
   return ar; } \

主要是加入了对>>的重载，但是没有重载<<，MFC仅提供了CObject对<<的重载，如下，

_AFX_INLINE CArchive& AFXAPI operator<<(CArchive& ar, const CObject* pOb)
 { ar.WriteObject(pOb); return ar; }

这是因为在序列化读和写的时候，都需要具体类的CRuntimeClass信息。相应的GetRuntimeClass()是一个虚函数，CObject重载<<，在写类信息时调用到该函数，由于虚函数机制，写入的是具体类的信息。但是这里隐含着一个条件，就是调用<<和GetRuntimeClass()时，具体类对象已经存在了，而调用>>和读入类信息时，该类对象还未被创建，所以无法利用这种机制，只能在每个具体类中都重载一次>>。我觉得《深入解析MFC》对这个问题的解释不正确。

这里有一个问题需要明确一下，序列化为什么要写入类信息？一是它应该保存完整的能够独立恢复对象的信息，二是在程序读入对象时，要把它的类信息和程序中期望的(所能处理的)类信息相比较，进行检验。

看IMPLEMENT_SERIAL宏对重载>>的实现，是提供一个期望的CRuntimeClass结构(用于检验)，委托CArchive进行对象读取。因为读对象时首先要跟文件打交道，所以交给CArchive处理，随后把读出的数据写入对象时，CArchive再调用具体类的Serialize()，如此合作是十分恰当的。在这里，CArchive还负责了读出和检验类信息，然后创建对象的过程。因为一方面具体类对象还不存在，另一方面这些操作对所有具体类都没有分别，应该提出来，在类级别实现或者让合作者实现。实际上，MFC先把这个过程交给CArchive::ReadClass()，后者又调用CRuntimeClass::Load()。 

对于序列化来说，搞清它的概念以后，就是实现Serialzie()，重载<<和>>。对<<和>>的重载涉及很多工作，MFC已经帮我们实现了，我们也看见了大概的设计，主要是与CArchive分工合作，其次是CRuntimeClass。

现在看到CRuntimeClass结构体在MFC对RTCI，动态创建和序列化的实现中都起着重要的作用，重新认识一下这个数据结构很有必要。

CRuntimeClass包含了关于类的各种信息和有关操作。把类及其基类的CRuntimeClass连成一个链表，就可以很方便地实现RTCI的IsKindOf()；把所有类的CRuntimeClass连成一个链表，再加上一个简单的CreateObject函数，就可以对以任意类名进行动态创建的企图做出反应；CRuntimeClass还实现了向文件读写类信息的Load()，Store()，配合序列化的实现。

在分析消息映射和命令传递机制之前，需要对Windows程序模型有很好的理解。

未完待续...


参考：

《深入解析MFC》/中国电力出版社
《深入浅出MFC》/华中科大出版社
《Windows程序设计》/北大出版社