ATL接口映射宏详解(中)

3.ATL::CComObjectRootBase::InternalQueryInterface(...)
2.COuter::_InternalQueryInterface(...)
1.ATL::CComObject< COuter >::QueryInterface(...)
解释：
static HRESULT WINAPI CreateInstance(void* pv, REFIID riid, LPVOID* ppv)
{
ATLASSERT(*ppv == NULL);
HRESULT hRes = E_OUTOFMEMORY;
T1* p = NULL;
ATLTRY(p = new T1(pv))
三、COM_INTERFACE_ENTRY_TEAR_OFF(iid, x) 参考ATL例程Beeper、COMMAP
使用这个宏的目的就是为了把一些很少用到的接口放在一个单独的组件中实现，仅当查询到这个接口时，才创建这个组件，并且当它的引用计数减为0时就会被释放掉。我们知道ATL中组件是通过多重继承实现的，每继承一个接口，在为它分配的内存块中就会多一个虚函数表指针，用这个宏就可以为每个组件的实例节省下这一个虚函数表指针来（一个指针4个字节，好象也不多啊，呵呵）
{
return m_pOwner->QueryInterface(iid, ppvObject);
}
还记得我们创建的分割组件是CComTearOffObject< CTearOff1 >吗？现在执行查询操作的是它的成员函数。它的实现很简单，事实上它什么也没做，仅仅是把它交给它的外部对象（即CComObject< COuter >)去做了。还记得m_pOwner是在构造函数里赋值的吧。现在是否感到有些不妙呢？呵呵
1--4:这些代码已经遇到过很多次了，我们还是集中精力看看核心代码：
ATLINLINE ATLAPI AtlInternalQueryInterface(void* pThis,
const _ATL_INTMAP_ENTRY* pEntries, REFIID iid, void** ppvObject)
{
_ATL_CREATORDATA* pcd = (_ATL_CREATORDATA*)dw;
return pcd->pFunc(pv, iid, ppvObject);
}
struct _ATL_CREATORDATA
{
_ATL_CREATORFUNC* pFunc;
};
我们继续用我们的老办法来跟踪一下看看它的执行过程。假设pOuter是我们已经获得的组件的IOuter接口指针。
执行pOuter->QueryInterface(IID_ITearOff1, (void **)&pTear1);
函数堆栈一：
7.CTearOff1::_InternalQueryInterface(...)
...........
COM_INTERFACE_ENTRY_TEAR_OFF(IID_ITearOff1, CTearOff1)
END_COM_MAP()
...........
};
CTearOff1实现了Tear-off接口ITearOff1，实现方法与其他组件并无不同。唯一不同的是它从CComTearOffObjectBase继承，CComTearOffObjectBase定义如下：
if (p != NULL)
{
p->SetVoid(pv);
p->InternalFinalConstructAddRef();
hRes = p->FinalConstruct();
p->InternalFinalConstructRelease();
if (hRes == S_OK) hRes = p->_InternalQueryInterface(riid, ppv);
}
还记得CTearOff1是从CComTearOffObjectBase继承的吗，这个基类包含了一个成员变量m_pOwner,现在它被赋值为指向它的外部对象的指针了。
7.现在终于把这个实现分割接口的组件创建了，剩下的在CTearOff1中查询ITearOff1的工作已经是重复劳动了，不再赘述。
6.ATL::CComInternalCreator< ATL::CComTearOffObject< CTearOff1 > >::CreateInstance(...)
5.ATL::CComObjectRootBase::_Creator(...)
4.ATL::AtlInternalQueryInterface(...)
if (hRes != S_OK) delete p;
}
return hRes;
}
};
同我们所见到的大多数Creator类一样，它也只有一个静态CreateInstance函数。现在我们终于可以创建我们分割组件了，它不是CTearOff1，它也是经了一层包装的，是 CComTearOffObject! 现在我们再来看看它的构造函数干了些什么事：
2、3： 果然，现在已经不用再看下去了，剩下的将是重复我们在调用第一条查询操作所做的一切。这个过程很简单，但它也隐含说明了一点：若对一个实现分割接口的组件每查询一次它的接口，就会调用一个新的实例！！！在上例中,最后的结果pTear2和pTear1 是不一样的！！这显然是浪费！
在下一节中，我们将介绍一个可以解决这个问题的宏！
四.COM_INTERFACE_ENTRY_CACHED_TEAR_OFF(iid, x, punk) 参ATL例程COMMAP
这个宏与上一节所讲的COM_INTERFACE_ENTRY_TEAR_OFF宏最主要的不同就在于，当查询分割对象中其他接口时，不会再新建新的对象。下面还是先看看它的典型用法：
{
public:
CTearOff1(){}
~CTearOff1(){}
BEGIN_COM_MAP(CTearOff1)
COM_INTERFACE_ENTRY(ITearOff1)
END_COM_MAP()
HRESULT STDMETHODCALLTYPE get_Name(BSTR* pbstrName)
我们先来看看COM_INTERFACE_ENTRY_TEAR_OFF的定义：
#define COM_INTERFACE_ENTRY_TEAR_OFF(iid, x)\
{&iid,\
(DWORD)&_CComCreatorData<\
CComInternalCreator< CComTearOffObject< x > >\
下面我们来看它的典型用法：
class CTearOff1: //该类是专门用来实现分割接口ITearOff1的
public IDispatchImpl< ITearOff1, &IID_ITearOff1, &LIBID_COMMAPLib >,
public CComTearOffObjectBase //外部对象
typedef HRESULT (WINAPI _ATL_CREATORFUNC)(void* pv, REFIID riid, LPVOID* ppv);
template < class Creator >
_ATL_CREATORDATA _CComCreatorData::data = {Creator::CreateInstance};
{
//..........
while (pEntries->pFunc != NULL)
{
BOOL bBlind = (pEntries->piid == NULL);
if (bBlind || InlineIsEqualGUID(*(pEntries->piid), iid))
>::data,\
_Creator},
看不太明白，还是继续我们路由得了
5:原来_Creator是CComObjectRootBase的静态成员函数，它可是COuter的一个基类啊，所以才可以这样写而不会编译出错。看看它的实现吧：
static HRESULT WINAPI _Creator(void* pv, REFIID iid, void** ppvObject,DWORD)
template < class Owner, class ThreadModel = CComObjectThreadModel >
class CComTearOffObjectBase : public CComObjectRootEx
{
public:
typedef Owner _OwnerClass;
执行pTear1->QueryInterface(ITearOff1, (void **)&pTear2)
一个实现分割接口的组件有可能包含多个分割接口，我们来检测一下它的查询过程。
函数堆栈二：
பைடு நூலகம்
4..............
3.COuter::_InternalQueryInterface(...)
{
*pbstrName = ::SysAllocString(L"ITearOff1");
return S_OK;