cexer

我觉得这种有点奇巧淫技的意思，不过调起BUG来真方便。多谢！

@LOGOS
多谢了，我也研究研究。

哪里有下载的源码

多重继承的时候，使用C风格的转换，可能会出乱子。

well done!

template<int i>
struct sum
{
enum{ result=sum<i-1>::result }
}

template<>
struct sum<1>
{
enum {result = 1 };
}

result = sum<n>::result;

@陈梓瀚(vczh)
是的，那东西还要再修改一下。

鉴于CPPBLOG上批判者多于探讨者，炫耀者多于分享者，陈同学分享代码是一个不容易的决定，谢谢并支持！！

我那个消息机制我自己已经放弃了，不过还是愿意与你探讨探讨。加我的QQ41086722

@proguru
最近就会写的。

@陈梓瀚(vczh)
不过如果你不接受类成员指针的话，那么你还是接受interface吧。仅仅接受一般函数会丧失很多能力的。

我写这个日志的主题在于实现一个通用的消息映射的数据结构，至于消息处理函数是是成员函数或自由函数，不在讨论范围内，并且那个很简单，也不用单独写篇日志。

@陈梓瀚(vczh)
现在只是封装映射的前半部分，下一篇会封装消息处理函数的类型。

@LOGOS
为什么说用一个for是不行的呢？这儿只是个示范。不一定非得用map。

@陈梓瀚(vczh)
囧，前两个月我发了free script于是大家都做脚本，一个月前我发了gui，大家就开始gui了……

@陈梓瀚(vczh)同学确实有着“抛玉引玉”的作用。再接再历！

@proguru
说的就是“特殊情况”。

@陈梓瀚(vczh)
曾经实现过类似HTML的，加了上脚本引擎，可配置能力和二次开发能力大大增强，用处还是很大的。

@proguru
自己用个map把窗口与指针装起来，另有好处。比如可以对map进行循环，进程结束时可以利用这个map做一些其它的事情，例如帮助用户销毁没有销毁的句柄，删除未删除的指针。

不错，Placement 那个有创意。不过用 WM_SIZE 消息来移动还是最灵活的。

@空明流转
有时候多个 GUI 线程还是很有用处的。比如说，用多线程模拟多进程，能够节省很多资源。像 Explorer.exe。或者 Emeditor 的多文档。

Welcome to the club!
研究“轮子功”的同志越来越多了哈。
不过我觉得 thunk 不是必须的哈。曾经用过 thunk，总是担心吊胆的怕它崩溃。因为它跟操作系统对内存代码的管理策略相关，有些操作系统在某些条件下可能会禁止提交可运行的内存块。仍然期待博主写出来哈！

@空明流转
节点的类型转换都是在解析完成以后的啊。如果是在循环当中用dynamic_cast，效率还是挺低的。

楼主幸福啊，我完全是造自学。。

@空明流转
系统怀疑你灌水，乱棒打出!

@陈梓瀚(vczh)
效率问题。dynamic_cast<>的比较的效率和字符串比较差不多，因此。。。不过想换成使用dynamic_cast<>也容易，直接
#define xml_cast dynamic_cast
就行了。

@陈梓瀚(vczh)
话说我的库的接口完全是Utf-16字符串的，然后我有一个Mbcs字符串类，俩能互转。所以用我的库的人要么用Utf-16，要么在每一个参数和返回值那里都去转。

一样的哈。

@陈梓瀚(vczh)
真是牛人，不过你的代码风格我不喜欢哈。

真是个牛逼的库，以前用过它的　CXTOutookbar。

有创意的哈，不过工程中不要有这种。

tinyxml对中文的支持太别扭了。

是的，这种细节就不要自己猜了，找本书看看，效率高些。

preprocessor，预处理元编程工具，包含重复和递归, 作者 Vesa Karvonen 和 Paul Mensonides.

有的时候宏的确实很有用，BOOST里面有一个预处理元编程库。

@空明流转
的确是半斤八两，不过虚函数还得查一下虚表，生成的汇编代码会有多几个寄存器操作，而静态的函数指针是直接call地址的。

@minji
我会把我的心得和方法写几篇日志出来，到时你看看吧。三言两语也不能说清楚。

@沈臻豪(foxtail)
指针也是有类型的，除了void*，但是放一大堆void*在一个容器里面，它的类型已经丢失，取出来的的时候就不知道怎么用这个void*进行函数调用了。

消息处理函数的参数类型限制得太死了，但是不同参数类型的函数你又无法放到一个容器里面去，这是写GUI框架一个基本的问题，看看你会怎么解决。

@jxfwinter
这个东西解释起来比较麻烦，我也不知道到底你是不是理解的和我想的一样。和 SmartWin 不大一样。定义即注册有两个意思，一是如果定义了函数则进行注册，二是如果没有定义函数就不注册，并不是像你说的在基类里预先注册过了。想像一下几千个消息，要一个个注册多麻烦。而且预先注册的方法，将会限制消息处理函数的名字。有时间我会把这个消息机制写几篇日志出来分析一下实现原理。

@jxfwinter
你没有看明白？
这个框架，函数定义即注册，只需要定义函数即可，已经用不着像 MESSAGE_HANDLER 宏，或者类似功能的东西了。这也是与一般的框架最大的不同。

确实有点古怪，那个 getnum() 明明是返回运行期数值。

兴趣驱动的人适合作艺术家。
毅力驱动的人更适合作程序员。

@陈梓瀚(vczh)
能够亲手制造一个漂亮性感用起来爽的轮子，再苦再累也值得啊．
你的意思是一个针对每一个event，都写一个handler类？
多谢提供代码，等我的框架有个成熟稳定了，也打算开放代码．

@陈梓瀚(vczh)
GUI 太复杂了，GUI Editor 不可能完成所有的工作．而且有了这些接口，GUI Editor 的相关部分要容易实现得多．

@陈梓瀚(vczh)
将event bind 到其它类的成员函数，或者全局函数，以前都实现过，不过不是很实用，干脆去掉了．对于全局函数，如果不是无参数的函数，那么给它提供运行时的参数是一件麻烦的事．因为设计框架的时候，并不知道用户会提供些什么类型的全局函数，如果把这件事给用户提供，用起来比较麻烦，接口看起来不简单明了．如果只允许提供特定的参数数目的类型，倒是很简单，不过就不实用了，所以后来就去掉了．
WM_COMMAND 和 WM_NOTIFY ，或者是其它消息的细节，框架都应该封装起来，不让最终的用户接触．

最好是选择自己喜欢的，要不做程序员会做得很痛苦．

@eXile
这倒是的．你说的这个问题，JLIB2（一个 C++ 版的 AWT ）就解决得很好，因为设计方式都是 java 的，所以和 WTL,MFC 之类的大大的不同．不过它大量地使用虚函数，存在性能问题．WinX 这个库的代码我也看过，它在 GUI 上几乎没有任何的创新，不能说它是一个独立的 GUI 框架．只能说是对 WTL 的小修补．

@eXile
多谢，我对QT用得不多，我会把你这个方法更新到日志上去．

我觉得模式二好一些．比如说如果因为某些原因产品的生产顺序需要改变，如果用模式一,国为每一个产品生产的时候是依赖其它产品的，所以需要更改产品链当中的相关产品的生产代码．但是如果用模式二，就只需要修改控制器的代码．

这个 DFA 还不是最小状态的吧?

@megax
这种方式的消息处理，要比 MFC 简单直接吧。你看到那么多的模板参数，最终的使用者是不会接触到的，都是框架用于扩展自身的。

@eXile
你说它没有更高阶的抽象，大概是因为你在代码里看到了一些 windows 上的类型。不过类型都是可以 typedef 的，消息值是可以 define 的。这个框架虽然是针对 windows 平台的，写这个框架的目的是尝试一种新的方式，对所有消息驱动的系统都是适用的，包括非 GUI 系统，或非 windows 平台。