我再次肯定了人们经常说的一话：也许真的要到了结束才知道去珍惜过往，去珍惜过去和大家在一起的时光。坦白说这次我走了，很疼，很痛苦，因为过去有太多的感动，太多的幸福。不知道是不是因为离别的时间越来越来近，现在的我们做什么好象都要加上“最后一次”，最后一次在工会里和大家说话，最后一次是恋爱之家的成员，最后一次看着工会里熟悉的面孔，最后一次……

　　我这段时间总是在想一个问题，我应该以什么样的方式去结束魔兽世界里的这段感情，又怎样去为它划上一个完美的句号。我不知道，也不敢在往下想，因为我真的已经习惯了这样的日子。现在的我，心情是复杂的，其实我早该预料到我们最终会走向这么一结局，我应该顺其自然些，但一些事情又何止是“顺其自然”四个字这么简单。

　　今天，我终于走了，不过与我想象中的有所不同，我前不久还在想怎样去划上这个句号，今天却……可不管是怎样的，结果却永远不会变，我走了，就这样的走了，最后还是要跟大家说声“对不起”，现在的我很难过，这样的离别让我背上了太多的伏罪感，脑海里回放着过去的点点滴滴，看着DKP记录里我们辉煌的瞬间，想起了以往的种种的感动，尽管这种感觉不能永驻心间，却在我心里划上了一到伤痕。

　　我们一起写的故事，后续已写不下去；

    已经没法再说更多的谎；

    说不出的寂寞，想求助的夜晚；

    我们一起写的故事，已经不需要加页；

    窗外月亮的光辉，照进孤独的房间；

    像被看穿一样，一直照到我心底；

    喜欢你的感觉，虽然现在也没有改变；

    但比起背叛心灵的痛苦，我选择离开。

在MFC的消息映射表的建立中，通过一组宏，你就可以让自己的类先于父类处理某些Windows消息，这种行为很像虚函数，只是我们重载的内容不是虚函数，而是消息。

推动消息的泵

第一阶段 窗口过程

在产生一个窗口的时候，会调用CFrameWnd::Create，所有的故事也都从这里展开。下面的代码为了简洁，去掉了不相关的代码

BOOL CFrameWnd::Create(…)  {
     //  …
     if  ( ! CreateEx(…))  {
         //  …
    }
     //  …
}

BOOL CWnd::CreateEx(…)  {
     //  …
    AfxHookWindowCreate( this );
    HWND hWnd  =  ::CreateWindowEx(…);
     //  …
}

void  AFXAPI AfxHookWindowCreate(CWnd *  pWnd)  {
     //  …
     if  (pThreadState -> m_hHookOldCbtFilter  ==  NULL)  {
        pThreadState -> m_hHookOldCbtFilter  =  ::SetWindowsHookEx(WH_CBT,
        _AfxCbtFilterHook, NULL, ::GetCurrentThreadId());
         //  …
    }
     //  …
    pThreadState -> m_pWndInit  =  pWnd;
}

这样，通过AfxHookWindowCreate，在当前线程中安装了一个钩子，用来拦截和窗口相关的事件，每当：

1. 另一个窗口成为active；
2. 产生或摧毁一个窗口
3. Minimize或maximize一个窗口；
4. 移动或缩放一个窗口；
5. 完成一个来自系统菜单的命令；
6. 从系统队列中取出一个消息；

时，都会先调用_AfxCbtFilterHook，接下来看看钩子函数作了什么：

LRESULT CALLBACK
_AfxCbtFilterHook( int  code, WPARAM wParam, LPARAM lParam)  {
     //  …
    WNDPROC afxWndProc  =  AfxGetAfxWndProc();
    oldWndProc  =  (WNDPROC)SetWindowLongPtr(hWnd, GWLP_WNDPROC,(DWORD_PTR)afxWndProc);
     //  …
}

WNDPROC AFXAPI AfxGetAfxWndProc()  {
     //  …
     return   & AfxWndProc;
}

这样，_AfxCbtFilterHook的工作总结起来就是通过窗口子类化，把新建的窗口的窗口过程设置成AfxWndProc。
到这里，我们终于找到了窗口过程。

结论
CFrameWnd::Create创建窗口调用CWnd::CreateEx
CWnd::CreateEx调用AfxHookWindowCreate准备为窗口设置钩子
AfxHookWindowCreate调用::SetWindowHookEx为窗口设置了一个WH_CBT类型的钩子来过滤消息，并把过滤函数设置成_AfxCbtFilterHook
_AfxCbtFilterHook通过窗口子类化设置窗口的窗口过程为AfxWndProc
这样，通过::DispatchMessage发送给窗口的消息就会源源不断地送到AfxWndProc中来，可以想到，AfxWndProc利用MFC的消息映射表，分门别类的对消息进行分流。

（待续……）

struct  AFX_MSGMAP_ENTRY
{
　　UINT nMessage;    //  windows message
　　UINT nCode;      　 //  control code or WM_NOTIFY code
　　UINT nID;        　　 //  control ID (or 0 for windows messages)
　　UINT nLastID;    　 //  used for entries specifying a range of control id's
　　UINT_PTR nSig;   　 //  signature type (action) or pointer to message #
　　AFX_PMSG pfn;     //  routine to call (or special value)
} ;

其中　typedef void (AFX_MSG_CALL CCmdTarget::*AFX_PMSG)(void);

之后，通过一个链表，把这些描述消息的结构组织起来，构成消息映射表的结构是AFX_MSGMAP

struct  AFX_MSGMAP　 {
　　 const  AFX_MSGMAP *  pBaseMap;
　　 const  AFX_MSGMAP_ENTRY *  lpEntries;
} ;

这样一个AFX_MSGMAP对象就成了构建消息映射表的关键人物，它一只手拉着基类的AFX_MSGMAP对象，另一只手拉着类本身的消息映射表，这样只要正确地在每一个类中都安插一个AFX_MSGMAP对象，那么整个消息映射表就建立起来了。那么，何为正确呢？含义有2：一是正确的设置pBaseMap，令它指向基类，二是正确的建立类自身的消息映射表。这两个工作是由4个宏完成的，

它们是：DECLARE_MEMSSAGE_MAP() / BEGIN_MESSAGE_MAP() / ON_COMMAND()（注：ON_COMMAND宏只是为了处理命令消息，对于其它的消息还有对应的宏，但是原理是相同的） / END_MESSAGE_MAP()。
让我们一个个的看看：

#define  DECLARE_MESSAGE_MAP() \
private : \
　　 static   const  AFX_MSGMAP_ENTRY _messageEntries[]; \
protected : \
　　 static   const  AFX_MSGMAP messageMap; \
　　 virtual   const  AFX_MSGMAP *  GetMessageMap()  const ; \

这个宏的作用有3：
 1. 在类中插入一个静态成员_messageEntries，这是用来存放类要处理的消息的数组（即类本身的消息映射表）
 2.  另一个静态成员massageMap用来指向基类的消息映射表
 3. 安插一个虚函数，其内容有待实现

接下来，_messageEntries的初始化，messageMap的正确指向，GetMessageMap函数的实现这些工作还都没做，那正是后三个宏的责任，它们要顺序使用，方能工作正常。

#define  BEGIN_MESSAGE_MAP(theClass, baseClass) \
   const  AFX_MSGMAP *  theClass::GetMessageMap()  const  \
   {  return   & theClass::messageMap; }  \
  AFX_COMDAT  const  AFX_MSGMAP theClass::messageMap  =  \
   {  & baseClass::messageMap,  & theClass::_messageEntries[ 0 ] } ; \
  AFX_COMDAT  const  AFX_MSGMAP_ENTRY theClass::_messageEntries[]  =  \
  { \

这个宏的作用有3：
1. 定义了安插在类中的虚函数GetMessageMap()，只是简单的返回messageMap对象的地址
2. 初始化messageMap，把派生类和基类联系起来构成一个大的消息映射表
3. 为类本身的消息映射表的初始化做语法准备

ON_COMMAND这个宏的作用就是向_messageEntries数组中添加类本身要处理的命令消息，其实在MFC中还有很多更方便的宏可以向类中添加消息，例如OM_WM_PAINT等，这里，我们主要讨论ON_COMMAND，毕竟原理都是相同的。

#define  ON_COMMAND(id, memberFxn) \
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSigCmd_v, \
  static_cast < AFX_PMSG >  (memberFxn) } ,

无非是对AFX_MSG_ENTRY结构的初始化，这样在类中为每一个想要处理的消息都是用一个ON_COMMAND宏，就自动的初始化了类本身的消息映射表。

最后，当全部的信息添加完毕后，使用END_MESSAGE_MAP()宏通知MFC一个类消息映射表结束了。

#define  END_MESSAGE_MAP() \
   { 0 ,  0 ,  0 ,  0 , AfxSig_end, (AFX_PMSG) 0  }  \
 }; \

实现手法单纯得很，无非是一个全0的AFX_MESSAGE_MAP对象。

结论
想要让你的类处理某个消息，使用下面的组合：

BEGIN_MESSAGE_MAP(theClass, the  base  Class)
// 消息处理宏
END_MESSAGE_MAP()

答案也许让你有些惊讶，我们可以利用sizeof来帮忙。你可以把sizeof用在任何复杂的表达式上， sizeof可以返回这个表达式值的大小，而不会在运行时评估表达式的值。这也就意味着，你可以把函数重载、模版实例化、转换规则等等所有你可以在C++表达式中使用的设施统统塞到sizeof中来。实际上，sizeof隐藏了一个可以演绎表达式类型的设施，最终，sizeof会返回表达式结果的类型。

这样我们就可以通过sizeof和重载函数来解决判断类型之间的可转换性的问题。思路很简单：我们提供2个重载函数，一个函数的参数是我们要转换成的类型（我们用U表示），而另一个则用来接收其他所有类型的参数。然后我们把要检测的类型（用T表示）传递给重载函数。如果接受类型U为参数的函数被调用了，我们就认为T可以转换为U，反之则不可以。如何确定哪个函数被调用了呢？我们利用sizeof出马，我们只要让重载函数返回不同的类型，然后检查一下返回值就可以了。

实践一下：

首先，定义2个不同的类型：

typedef  char  Small;
class  Big  {  char  dummy[ 2 ]; } ;

默认情况下， sizeof(Small) 是 1 ，而 Big 的大小则无关紧要，我们只要知道肯定不是 1 就好了。

其次，定义 2 个重载函数，一个接收要转换成的类型：

Small Test(U);

另一个用来接收“其他的所有类型”，我们要保证在排除所有的转换之后才调用这个函数， OK, 用省略号表示的参数列表真好满足需求

Big Test(...);

尽管把一个 C++ 对象传递给 ... 参数类型的函数，其结果未定义，但是实际上我们并没有调用这个函数。我们甚至可以不用实现它。

最后，我们用 sizeof 判断一下就完成任务了：

const   bool  convExist  =   sizeof (Test(T()))  ==   sizeof (Small);

你也许会说，就是它了！ Test 的调用会创建一个临时对象 T ，之后可能的结果只能是 sizeof(Small) 或 sizeof(Big) 。兴奋之余，我们还要看到一个问题。如果 T 的构造函数被设计成 private ，我们就前功尽弃了。当然解决的方法也很简单，定义一个函数，让他返回类型为 T 的对象。

T MakeT();
const   bool  convExist  =   sizeof (Test(MakeT()))  ==   sizeof (Small);

最后，把刚才的东西封装到一个类里：

template  < class  T,  class  U >
class  Conversion  {
    typedef  char  Small;
     class  Big  {  char  dummy[ 2 ]; } ;

     static  Small Test(U);
     static  Big Test();
     static  T MakeT();

public :
     enum   { exist  =   sizeof (Test(MakeT()))  ==   sizeof (Small) } ;
} ;

另外，我们还可以设置另外一个常量 Conversion::SameType ，如果 T 和 U 表示同一个类型，那么返回 true ：

template  < class  T,  class  U >
class  Conversion  {
    ..  as  above..
     enum   { sameType  =   false }
} ;

之后为同一个类型设计一个偏特化版本：

template  < class  T >
class  Conversion < T, T >   {
     enum   { exists  =   1 , sameType  =   1  } ;
} ;

最后，回到我们的主题，通过 Conversion 的帮助，我们可以来决定两个类型的继承性了。

#define  SUPERSUBCLASS(T, U) \
    (Conversion < const  U * ,  const  T * )::exists  &&  \
     ! Conversion < const  T * ,  const   void *> ::sameType)

当 U 继承于 T 或者 U 和 T 是同一个类型的时候， SUPERSUBCLASS 返回 true 。总结一下，只有下面这 3 种情形 const U* 可以隐式转换到 const T* ：

1.      T 和 U 是同一个类型

2.      T 是 U 的任意一个基类

3.      T 是 void

我们通过第 2 个测试屏蔽了最后一种情形。当然，如果你认为同一种类型也不算是继承关系的话，可以进一步严格其条件：

#define  SUPERSUBCLASS_STRICT(T, U) \
    (SUPERSUBCLASS(T, U)  &&  \
     ! Conversion( const  T,  const  U)::sameType)