ATL的艺术(一)-实现简单COM对象

ATL的艺术(一)-实现简单COM对象

关键词： ATL    WTL    VC++                                          

 

以一个DropTarget为例，我们都知道在MFC里有COleDropTarget实现OLE拖放目标端非常容易,缺点MFC太臃肿近八年没有更新过了,而且功能类与窗体类分离代

码不够紧凑,那么在ATL/WTL中要实现DropTarget也是非常的容易的,而且更码更加紧凑完美,完美的有点变态,呵呵!

我觉得ATL小组的人曾经一定是些汇编语言狂热者,因为ATL的运行效率真的是太高了,非常高,难以想象的高.(如果你偏不信可以用WTL向导一个空工程,Release编

译后再用反汇编工具反一下,看看生成的代码质量如何,特别是使用VC6以后版本的VC++编译器编译)

首先向导一个空的不带工具栏和状态栏的WTL SDI工程,Viwe type选择Edit这样我们会得到一个类似Notepad界面的程序,然后分成6步完成拖放支持

1.在stdafx.h里加上以下语句:
#include <atlcom.h>
意义是使用ATL的COM支持类,包括CComObject,CComPtr等

2.在WinMain里:
在::CoInitialize(NULL)语句后加入以下语句
::OleInitialize(NULL);
以及在
::CoUninitialize()语句前加入以下语句
::OleUninitialize();

意义是在单线程套间中初使化COM库,初使化后便可使用以下功能
a,剪贴板(Clipboard)
b,拖与放(Drag & Drop)
c,对象连接与嵌入(Object linking and embedding,OLE)
d,就地激活(In-place activation)

我原来一直以为使用CoInitialize就可以了,可我调用RegisterDragDrop总
是失败,并返回E_OUTOFMEMORY,直到我仔细看了函数说明看到下面这句话:
Note  
If you use CoInitialize or CoInitializeEx instead of OleInitialize
to initialize COM, RegisterDragDrop will always
return an E_OUTOFMEMORY error.
很多时候bug都是因为不仔细产生的,呵呵!

3.将CComObjectRoot和IDropTarget加入CMainFrame的派生列表
class CMainFrame : public CFrameWindowImpl<CMainFrame>,...,
 public CComObjectRootEx<CComSingleThreadModel>,public IDropTarget

4.定义标准DropTarget方法
在MainFrm.h的CMainFrm的类定义中定义标准的IDropTarget方法:
STDMETHOD(DragEnter)(IDataObject * pDataObject,DWORD grfKeyState,POINTL pt,DWORD * pdwEffect);
STDMETHOD(DragOver)(DWORD grfKeyState,POINTL pt,DWORD * pdwEffect);
STDMETHOD(DragLeave)();
STDMETHOD(Drop)(IDataObject * pDataObject,DWORD grfKeyState,POINTL pt,DWORD * pdwEffect);

并在实现文件MainFrm.cpp实现它们.

FORMATETC fe={0};
STDMETHODIMP CMainFrame::DragEnter(IDataObject * pDataObject,DWORD grfKeyState,POINTL pt,DWORD * pdwEffect)
{
 CComPtr<IEnumFORMATETC> pEnum;
 pDataObject->EnumFormatEtc(DATADIR_GET,&pEnum);
 while(pEnum->Next(1,&fe,NULL)==NO_ERROR)
 {
  if(fe.cfFormat==CF_TEXT)
  {
   *pdwEffect=DROPEFFECT_COPY;
   break;
  }
 }
 return S_OK;
}
STDMETHODIMP CMainFrame::DragOver(DWORD grfKeyState,POINTL pt,DWORD * pdwEffect)
{
 *pdwEffect=DROPEFFECT_COPY;
 return S_OK;
}

STDMETHODIMP CMainFrame::DragLeave()
{
 return S_OK;
}

STDMETHODIMP CMainFrame::Drop(IDataObject * pDataObject,DWORD grfKeyState,POINTL pt,DWORD * pdwEffect)
{
 STGMEDIUM stg={0};
 pDataObject->GetData(&fe,&stg);
 LPCTSTR lpData=(LPCTSTR)GlobalLock(stg.hGlobal);

 m_view.SetWindowText(lpData);

 GlobalUnlock(stg.hGlobal);
 ReleaseStgMedium(&stg);

 *pdwEffect=DROPEFFECT_COPY;
 return S_OK;
}

5.定义COM映射表
在MainFrm.h的CMainFrm的类定义中加入下面几句:
BEGIN_COM_MAP(CMainFrame)
 COM_INTERFACE_ENTRY(IDropTarget)
END_COM_MAP()

6.注册和注销
在WM_CREATE消息的Handler OnCreate中注册
RegisterDragDrop(m_hWnd,this);
在WM_CLOSE消息的Handler OnClose中注销
RevokeDragDrop(m_hWnd);

现在差不多已经完成了,在这里不要问怎么没有见到你写AddRef,Release,QueryInterface,ATL为我们提供了非常高效且多线程安全的实现,我们要做的只是实

现不同的接口,COM对象的生存周期管理是基于"在堆中生成对象"的假设(否则还AddRef,Release干什么).这里我们的主窗体对象也将在堆中生成.

修改一下Run函数,像下面这样来生成主窗体
int Run(LPTSTR /*lpstrCmdLine*/ = NULL, int nCmdShow = SW_SHOWDEFAULT)
{
 CMessageLoop theLoop;
 _Module.AddMessageLoop(&theLoop);

 //一个COM对象指针
 CComObject<CMainFrame> *pMainFrm=NULL;
 //在堆上分配对象
 CComObject<CMainFrame>::CreateInstance(&pMainFrm);

 if(pMainFrm->CreateEx() == NULL)
 {
  ATLTRACE(_T("Main window creation failed!/n"));
  return 0;
 }

 //增加引用计数,COM的老规矩,不用我多说
 pMainFrm->AddRef();
 pMainFrm->ShowWindow(nCmdShow);
 
 //开始消息循环,Release编译后都是展开的
 //直接调用GetMessage,TranslateMessage.....
 int nRet = theLoop.Run();
 
 //减少引用计数,COM的老规矩,这里的计数为1,
 //调用Release后对象自动析构
 pMainFrm->Release();

 _Module.RemoveMessageLoop();
 return nRet;
}

运行一下,可以从WinWord里拖放文本到这个小程序里.

从注册时的RegisterDragDrop(m_hWnd,this)调用可以看到窗口对象和COM对象完美的融合到了一起,在COM方法中可以很方便的与其它组成部分交互,比如Drop
方法中的m_view.SetWindowText(lpData)调用.为什么this可以自动转成IDropTarget指针呢,因为我们的CMainFrame继承了IDropTarget抽像类,所以按
照面向对象的观念来看CMainFrame类"是一个"IDropTarget类.

其实在CMainFrame中只有少数接口继承来的函数会生成函数体,其它的如消息处理过程OnCreate,OnClose等如果代码不是很多,最后都会内联到一个叫做
ProcessWindowMessage的函数中,由一个大大的switch来处理.

再优化一下,我们如果接口继承的层次太多(其实这个例子里不多),便会生成庞大虚函数表,从而影响性能,这是一些偏执狂对C++一直都指责的地方,给CMainFrame
加上ATL_NO_VTABLE(__declspec(novtable))定义,这样如果是从CMainFrame继承,也只到最后的实现类才生成虚函数表.

使用默认的Release编译选项(最大化速度优先)编译生成的exe只有36K,而一个Win32 Application向导生成的带窗口空工程编译后都有40K了,知道为什么吗?
呵呵,因为ATL在Release编译时用更小更快的启动代码面不是_WinMainCRTStartup之类的东东,并且不使用CRT,C++ RTTI,C++异常处理,以及自
定义了一套malloc,new,free,delete之类的函数和运算符(这不就是使用C++语法在写C程序嘛!或者说比C更高效,连CRT都不用),如果再加上

/opt:nowin98,/align之类的指示便会更小.

总之,在我的脑海里:ATL+WTL=快速小巧且界面漂亮的程序,:-)

其实这些优化在机器性能猛增的今天已经变的微不足道,毕竟开发工作不全都是在处理海量的多媒体数据.现在用MFC的人都少了,更不用说ATL这样出力不讨好的东

东,大家都在搞.NET用C#之类的东东,我一直很不喜欢解释执行的东东,可往后每台电脑都有了.NET Framework,就不存在托管代码和本地代码之分了,反正发布的

软件在哪台电脑里都能运行,就像你用Windows API来写程序,系统中已经带好了相关的DLL,以后用.NET框架来写程序,系统中也有.NET程序的运行时环境,用户不

会管你是真编译的还是解释执行的或是你少用了几个时钟周期,发现自己需要转变一下那种偏执狂的想法.也许什么时候我应该接受C#或是Java.....