显示标签为“template”的博文。显示所有博文
显示标签为“template”的博文。显示所有博文

星期日, 十一月 05, 2006

WINX的消息分派机制(续)

和MFC、WTL等界面库不太一样的是,WINX认为消息分派是一个可独立于窗口存在的基础服务。所以WINX中负责消息分派的不是 winx::Window<T>类,而是 winx::WindowMessage<T>类。 winx::Window<T>只是从winx::WindowMessage <T>继承。

上一篇我故意买了个关子。如果有读者在看了《WINX的消息分派机制 》一文后去亲自看winx的头文件了解实地了解一下的话,我将觉得很安慰。这一篇我们继续这个话题。

WindowMessage<T>的基本规格是这样的:

template <class T>
class WindowMessage
{
 void OnDestroy(HWND hWnd);
 void OnPaint(HWND hWnd);
 void OnKeyDown(HWND hWnd , UINT uVKChar, UINT uKeyData);
 ...

 LRESULT InternalDefault (
   HWND hWnd, UINT message,
   WPARAM wParam , LPARAM lParam);

 BOOL DispatchMessage (
   HWND hWnd , UINT message,
   WPARAM wParam , LPARAM lParam, LRESULT& lResult);

 LRESULT ProcessMessage(
   HWND hWnd, UINT message ,
   WPARAM wParam, LPARAM lParam);
};

按 WindowMessage<T>的契约,其客户必须将发送给窗口的所有消息全部转发给ProcessMessage函数进行处理。涉及的几个关键函数功能如下:

  • ProcessMessage函数先调用DispatchMessage对消息分发,如果DispatchMessage 没有处理该消息,则调用InternalDefault来处理该消息。
  • DispatchMessage函数根据消息的ID,即UINT message参数,对消息进行分派。例如WM_PAINT消息发送给OnPaint处理,WM_DESTROY发送给OnDestroy处理,WM_KEYDOWN发送给OnKeyDown处理等等。
  • InternalDefault函数则是抽象不同类型的窗口。对于普通窗口,它调用DefWindowProc;但对于MDIFrame窗口,它需要调用DefFrameProc;对于MDIChildFrame窗口,则调用DefMDIChildProc;对于对话框,则它只需要直接返回FALSE即可。
显然,这里面最为关键的是 DispatchMessage 。如果不考虑优化,它看起来并不复杂。我们这里实作一个基于虚函数(virtual)机制的版本:

class WindowMessage
{
 virtual void OnPaint(HWND hWnd) { Default(); }
 virtual void OnKeyDown(
   HWND hWnd, UINT uVKChar, UINT uKeyData) { Default(); }
 ...
 
 LRESULT Default();
 
 BOOL DispatchMessage(
   HWND hWnd, UINT message,
   WPARAM wParam , LPARAM lParam, LRESULT& lResult)
 {
  switch (message)
  {
  case WM_PAINT: OnPaint(hWnd); break;
  case WM_KEYDOWN: OnKeyDown(hWnd, wParam, lParam); break;
  ...
  default: return FALSE;
  }
  return TRUE;
 }
};
 
你一定对此不屑一顾:除了Default函数看起来有点意思(容后介绍它的实现)外,用一个超庞大switch..case来实现DispatchMessage,有"创意",但实在是有些乏味。
 
有人马上提建议说,改用模板(template)吧�D�D性能高些。于是,就有了基于template的版本:
 
template <class T>
class WindowMessage
{
 void OnPaint(HWND hWnd) { Default(); }
 void OnKeyDown(HWND hWnd, UINT uVKChar, UINT uKeyData)
  { Default(); }
 ...
 
 LRESULT Default();
 
 BOOL DispatchMessage(
   HWND hWnd, UINT message,
   WPARAM wParam , LPARAM lParam, LRESULT& lResult)
 {
  T* pThis = static_cast<T*>(this);
  switch (message)
  {
  case WM_PAINT: pThis->OnPaint(hWnd); break;
  case WM_KEYDOWN: pThis->OnKeyDown(hWnd, wParam, lParam); break;
  ...
  default: return FALSE;
  }
  return TRUE;
 }
};
 
在很多时候,模板(template)与虚拟(virtual)是相通的。这两个版本的WindowMessage并无本质的不同,事实上只是作了机械的代码变换而已。了解这个变换的等价性是很有必要的。不可否认,经此一变,性能提高了不少。前文《 ATL界面类——兼谈多态与泛型 》我们对此作了细述。
 
这个基于模板的WindowMessage类同样乏味。尽管没有了虚函数调用的开销,但这个DispatchMessage函数无疑仍然是个庞然大物,与WTL的精巧相去甚远。
 
那么,我们还有甚么办法可想吗?
 
to be continued...

星期四, 十月 19, 2006

ATL界面类——兼谈多态与泛型

由于业余时间相对比较少,并且接下来要出差(大约十天左右),看样子winxcn.com短期内不能出来。为了WINX的文档不至于遥遥无期,我决定还是现在开始在blog上连载WINX的核心文档。或许对于这些文档而言,blog不是一个很好的载体,因为blog更关注的是社会性,强调的是参与,而体系性较差。

这是开篇第一篇。你可能觉得惊奇——不是要讲WINX吗?怎么,讲ATL来着?勿须奇怪,WINX是基于ATL/WTL的,所以,在讲WINX的原理之前,先要了解ATL的基本概念,它们一定程度上是相通的。

ATL/WTL的界面开发,网上的教程还是少了点。相信大家都知道《MFC程序员的WTL开发指南》,这的确是一套难得的好教材。作为WINX的入门篇,我们这一篇是回顾《MFC程序员的WTL开发指南》第一篇:“ATL界面类”(注:为了不至于重复制造轮子,我这里不再赘述该文章已经叙述较为详细的一些技术细节)。

接触ATL/WTL久了,类似下面这样的代码你一定见得多了:

class MyClass : BaseClassT<MyClass>
{
};

把派生类MyClass,作为模版参数传递给基类BaseClassT,这种写法多多少少显得有点古怪。但这是合法的。之所以要这样,是因为我们要实现“编译期的晚绑定”(ATL界面类中把它称为“编译期间的虚函数调用机制”,这是不太准确的说法)。

基于虚函数技术的“运行期(Runtime)的晚绑定”大家都已经很熟悉了,这也就是OOP中所谓的“多态”。而基于模板技术,所依赖的并非vtable,而是类型不确定型(类型晚绑定),来达到“编译期的晚绑定”。这也就是所谓的“泛型”。

选择“多态(虚函数技术)”,还是选择“泛型(模板技术)”?

模板的好处是“零开销”——即额外的时间、空间开销均为零。而虚函数技术在时间上多了一次间接调用(由vptr找到vtable中相应的函数地址),并导致inline失效(无法展开);在空间上每个类对象多了4字节(这里假设是32bit系统)的vptr,全局多了一个vtable(大小与该类的虚函数个数有关)。

虚函数的好处是“可定义二进制规范”,从而建立语言无关的调用约定。这就是COM(组件对象模型)技术关注的内容。进一步来说,虚函数技术比较适合应用于大型程序中的模块划分,用以描述组件间调用契约——interface(接口)。

我并不是模板技术的推崇者。应当认识到,模板与虚函数技术一样,只适合有限的场合。WINX中,消息分派机制使用了模板,是因为它是最适合的人选。

作为结束,我提醒读者,理解泛型中的“编译期的晚绑定”是重要的,如果你希望深入理解WINX的话。下一节我们开始进入最关键的章节——WINX的消息机制。