C++博客-游戏人生-最新评论

re: 消息映射机制的简单实现[未登录]

cppexplore — Thu, 19 Feb 2009 02:16:00 GMT

@OwnWaterloo
呵呵你觉得你的想法来源于面向对象的纸上谈兵（没有贬义）以及基于win32的mfc框架程序设计。
我的实现不是为了模拟虚函数的实现，只是为了实现一个易维护的消息映射而已。
首先对象A不能直接向对象B直接发送消息，需要调用对象B的ON_send_msg，由B自己的方法向自己发送消息，由B的DO_Msg方法处理消息，当然发送动作和处理动作在不同的线程内。任何对象向B发送消息都要调用B自己的方法。也就是说对象B的具体消息类型对其它对象是不可见的。
因此对象B中的消息类型是连续的，并且不存在自己不感兴趣的消息，既然不感兴趣，就不会存在这个消息类型，只要是存在的就是感兴趣的，就是要处理的。也不存在对多个消息，处理方式相同的问题，既然处理方式相同，它们就是同一个消息。
其次你还是回避了大型程序开发中，使用虚函数方式，文件个数膨胀的问题。
最后我讨论的是线程间的消息传递和映射，你的有偏向于已经发送到UI线程的消息，对责任链模式上的各个对象的后续处理。

cppexplore 2009-02-19 10:16 发表评论

re: 消息映射机制的简单实现

OwnWaterloo — Wed, 18 Feb 2009 18:16:00 GMT

考虑扩展

添加一个新的消息处理类。

如果基类不是纯虚函数，那最简单了，覆写需要关心的消息就可以了。

如果是纯虚函数，需要实现所有消息处理函数，对不关心的消息，使用基类默认处理。

而你的方案，不得不将所有的消息都映射一遍——因为【消息类型做数组下标，直接定位取处理函数】——即使不关心而作一个空函数。

BEGIN_MESSAGE_MAP(SessionManager,SessionMsg)
    ON_MESSAGE(MSG_TYPE_1, SessionManager::do_msg_type_1_)
    ON_MESSAGE(MSG_TYPE_2, SessionManager::do_msg_type_2_)
    // .. MORE
END_MESSAGE_MAP()

如果不是这样，请务必告诉我你是怎么不使用虚函数实现的。

添加一个新的消息种类（消息代码）

如果可以保证消息代码连续，可以使用上面的方案2，在表格中多加入一条。

如果不能保证消息代码连续（并且非常稀疏），就只能采用swtich case。

已经编写好的具体的消息处理类，如果都可以安全忽略该消息，那么可以采用上面的方案2——基类有默认实现且不纯虚——那么除了基类，已经编写好的具体类都不需要修改。

如果不全都可以安全忽略该消息，那么可以采用上面的方案1——基类有空实现，但是纯虚——具类中可以忽略该消息的，使用基类实现，不能忽略的，编写处理函数。

而你的方案，一旦添加一个新的消息处理代码（同时要保证连续），所有的消息处理类都必须在其表格中增加一项。

OwnWaterloo 2009-02-19 02:16 发表评论

re: 消息映射机制的简单实现

OwnWaterloo — Wed, 18 Feb 2009 18:16:00 GMT

移植性确实会在不支持虚函数的语言中完败。
论理解、扩展、维护、简单的话，你现在仍然觉得虚函数比不上表格吗？

OwnWaterloo 2009-02-19 02:16 发表评论

re: 消息映射机制的简单实现

OwnWaterloo — Wed, 18 Feb 2009 17:57:00 GMT

@cppexplore

【怎么不直接去我blog回复呢呵呵】
好像是cppblog对url的分析有点问题，这个url： http://www.cppblog.com/CppExplore/archive/2008/11/07/66216.html
会被截取，只将前面一部分（也就是你的主页）制作成链接，点过去没看见什么文章……
后来才发现这个问题，找到那篇文章……

【容易理解，容易扩展，容易维护，容易移植，容易简单化】
嗯，这是重点。同时我也赞同你文章里最后一句话【一句话:重要的是思想，不是平台和语言。】

"你的实现就是模拟C++虚函数的经典实现"，这个观点你赞同吗？
你的系统需要考虑向C（以及不支持虚函数的语言）移植吗？

如果赞同且不需要，那么继续讨论理解、扩展、维护、简单。

你的系统具体要做什么不太了解，我用win32作例子可以吗？比如，现在需要关心的消息只有2个：

enum MsgType {
    WM__LBUTTONDOWN /*= 0*/,
    WM__SIZING,
    //
};
struct Msg {
    MsgType type;
    HWND    hwnd;
    WPARAM  wparam;
    LPARAM  lparam;
};

如果使用C++虚函数机制：

class IHandler {
public:
    virtual ~IHandler() {};
protected:
    virtual void OnLButtonDown(POINTS pt,bool ctrl,bool shift,bool l,bool m,bool r) = 0 {};
    virtual void OnSizing(RECT& rc,int side) = 0 {};
public:
    LRESULT Do(Msg* msg) {
        switch (msg->type) {
            case WM__LBUTTONDOWN:
                OnLButtonDown(MAKEPOINTS(msg->lparam)
                             ,msg->wparam & MK_CONTROL
                             ,msg->wparam & MK_SHIFT
                             ,msg->wparam & MK_LBUTTON
                             ,msg->wparam & MK_MBUTTON
                             ,msg->wparam & MK_RBUTTON);
                return 0;
            case WM__SIZING:
                OnSizing(*reinterpret_cast<RECT*>(msg->lparam),msg->wparam);
                return 0;
        }
        return DefWindowProc(msg->hwnd,msg->type,msg->wparam,msg->lparam);
    }
};

具体的消息处理类可以这样：

class Handler1 : public IHandler {
    void OnLButtonDown(POINTS pt,bool ctrl,bool shift,bool l,bool m,bool r) {
        IHandler::OnLButtonDown(pt,ctrl,shift,l,m,r);
    }
    void OnSizing(RECT& rc,int side) {
        IHandler::OnSizing(rc,side);
    }
};

上面的基类的虚函数带有默认实现，但设置为纯虚函数。

具体类必须实现每个消息处理过程，如果不关心，可以简单使用基类实现。

另一种方式：基类提供默认实现，并且不是纯虚函数；具体类只需覆写关心的消息。

另一方面，上面的基类没有使用表格，如果觉得switch case 不好维护，也可以使用表格。

两方面都采用另一种方案的话，基类就如下：

class IHandler {
public:
    virtual ~IHandler() {};
private:
    virtual void OnLButtonDown(POINTS pt,bool ctrl,bool shift,bool l,bool m,bool r)  {};
    virtual void OnSizing(RECT& rc,int side)  {};
public:
    LRESULT Do(Msg* msg) {
        assert(msg->type>=0 && msg->type<WM__SIZING);
        return MsgProcs[msg->type](msg->hwnd,msg->type,msg->wparam,msg->lparam,this);
    }

private:
    typedef LRESULT (*MsgProc)(HWND,MsgType,WPARAM,LPARAM,IHandler* handler);
    const static MsgProc MsgProcs[];
    static LRESULT OnLButtonDown(HWND,MsgType,WPARAM wparam,LPARAM lparam,IHandler* handler) {
        handler->OnLButtonDown(MAKEPOINTS(lparam)
                              ,wparam & MK_CONTROL
                              ,wparam & MK_SHIFT
                              ,wparam & MK_LBUTTON
                              ,wparam & MK_MBUTTON
                              ,wparam & MK_RBUTTON);
        return 0;
    }
    static LRESULT OnSizing(HWND,MsgType,WPARAM wparam,LPARAM lparam,IHandler* handler) {
        handler->OnSizing(*reinterpret_cast<RECT*>(lparam),wparam);
        return 0;
    }
};

const IHandler::MsgProc IHandler::MsgProcs[] = {
    IHandler::OnLButtonDown,
    IHandler::OnSizing,
};

具体类的编写就更简单：假设仅关心OnLButtonDown

class Handler1 : public IHandler {
    void OnLButtonDown(POINTS pt,bool ctrl,bool shift,bool l,bool m,bool r) {
        printf("(%d,%d) ctrl=%d,shitf=%d\n",pt.x,pt.y,ctrl,shift);
    }
};

OwnWaterloo 2009-02-19 01:57 发表评论

re: 消息映射机制的简单实现[未登录]

cppexplore — Wed, 18 Feb 2009 10:55:00 GMT

@OwnWaterloo
呵呵，最后的问题归结为：哪种更容易理解和扩展。
超大工程当然是数组方式之上用宏展现最容易理解和扩展了，简洁直接。几十w行的代码，用虚函数，文件数量的迅速膨胀找个东西都找不到在哪里，所有东西交织错乱在一起，最终维护程序的人都会想：要是有张表就好了，只看表就知道那个函数处理哪个消息，而宏的展现就是如此。当然如果用宏包裹下虚函数的实现，结果就一样了。
并且数组表只是一个思路，不携带任何面向对象的语义，在这个业务系统里可用，在那个业务系统里也可用，虚函数有这么好的移植性吗？有这么简单化吗？

cppexplore 2009-02-18 18:55 发表评论

re: 消息映射机制的简单实现[未登录]

cppexplore — Wed, 18 Feb 2009 10:21:00 GMT

@OwnWaterloo
怎么不直接去我blog回复呢呵呵
其实时间消耗之类并不是我最得意的东西，这种实现的细节我并不太关注，所以质疑你以前说的 “虚函数占用较多资源而导致不得已采用消息路由”，如何实现并不重要，关键的是容易理解，容易扩展，容易维护，容易移植，容易简单化。
win32 你是指win32 的界面设计？业务系统里基本不同的消息有不同的实现，我的本意其实都不在实现，而在于简单的思想，因此是查表实现还是虚函数实现也都无所谓，只要最后有统一的扩展方式。

cppexplore 2009-02-18 18:21 发表评论

re: 消息映射机制的简单实现

OwnWaterloo — Wed, 18 Feb 2009 10:03:00 GMT

@cppexplore

再看了下你的实现，好像我们讨论的着重点不一样。

1. 你的系统里，是不是首先有这样一个需求：

因为某种原因（分布式，进程间，无锁线程），消息的发送者不能直接调用消息处理函数，而是传送一个消息代码来表示需要处理的类型？

消息代码即是win32中的WM_XX或者你的系统中的 enum MsgType { MSG_TYPE_1＝65, ... };

2. 消息的处理者，又需要按照约定（即消息代码的含义），将其映射到某个处理函数中。

如 win32 中

switch (message) {

case WM_XXX:

return OnXXX(hwnd,message,wparam,lparam);

...

}

或者你的系统中的

switch(msg->type)
{
    case MSG_TYPE_1:
         do_msg_type_1_();
         break;
    case MSG_TYPE_2:
         do_msg_type_2_();
         break;
    ..
    default:
             do_default_msg_();
             break;
}

在这一步，确实是你的实现方式时间效率比较高。

但是在win32中，这样做不太现实 …… 1000多个消息，表格就要包含1000多项，而且大多都是DefWndProc。

并且，在这一步中，虚函数根本就提供不了任何帮助。

你的着重点在这一步？

3. 你想实现一个消息处理者B，它对大多数消息的处理方式同A一样，这时候如何尽可能的使用A的实现？

（暂不说依赖于某实现是不太恰当的设计，在MFC中多如牛毛……）

我的着重点在这里，我对处理这步的观点是：『消息类型做数组下标了，直接定位取处理函数』与『覆写虚函数』相比，时空效率是相同的，我觉得后者更容易理解和扩展。

OwnWaterloo 2009-02-18 18:03 发表评论

re: 消息映射机制的简单实现

OwnWaterloo — Wed, 18 Feb 2009 08:40:00 GMT

@cppexplore

【查表是本质】
这句你说到重点了，虚函数和你实现的那个还有哪些所谓的用C实现OO的，都是查表。

【为什么要使用虚函数？更容易理解?MFC的消息映射展现方式很难理解吗？虚函数更容易扩展吗？】
你这个实现就是在『模拟』虚函数。

上面的时空分析，可以量化，我有把握你会同意我的观点——两者时空效率完全一样——这个扩展性嘛，不容易量化 ……

你可以试着把你的实现用虚函数改写一下（再次说明，时空效率完全一样）。看看是否觉得虚函数更容易理解，更容易扩展。

btw：推荐你看看这个，MFC会什么会采用消息映射而不是虚函数的理由，《C++多态技术的实现和反思》
http://dev.yesky.com/189/2385189.shtml

OwnWaterloo 2009-02-18 16:40 发表评论

re: 消息映射机制的简单实现

OwnWaterloo — Wed, 18 Feb 2009 08:29:00 GMT

@cppexplore

1. 时间消耗

时间消耗自然不用说，是你的实现最得意的部分，o(1)。
同样，虚函数也是o(1)。

2. 空间消耗

假设你总共有N个消息，你仔细看看你的实现：
是不是每个（要处理消息的）类有一个长度会N的函数表，
空间大小至少是N×sizeof(void*)；
每个对象有一个指向（或间接指向）该表的指针，
空间大小至少是sizeof(void*)。

虚函数的经典实现的空间消耗也是one class one vtbl, one object one vptr，和你的实现还是相同的。

这就回答了你一个问题：
【我不能认同，这个因素在整个系统中的开销你有没有量化过？比如因为采用它导致并发数下降了多少多少之类？】
两者的时间空间效率是完全一致的，即使我没有量化过，也可以肯定，不会导致并发数下降。

OwnWaterloo 2009-02-18 16:29 发表评论

re: 消息映射机制的简单实现[未登录]

cppexplore — Wed, 18 Feb 2009 04:00:00 GMT

@OwnWaterloo
欢迎来我blog讨论：http://www.cppblog.com/CppExplore 这篇http://www.cppblog.com/CppExplore/archive/2008/11/07/66216.html下。查表是本质，为什么要使用虚函数？更容易理解?MFC的消息映射展现方式很难理解吗？虚函数更容易扩展吗？说到虚函数占用较多资源而导致不得已采用消息路由，我不能认同，这个因素在整个系统中的开销你有没有量化过？比如因为采用它导致并发数下降了多少多少之类？欢迎来我blog讨论。

cppexplore 2009-02-18 12:00 发表评论