（转）COM开发拾粹

最新推荐文章于 2025-07-17 21:12:39 发布

liujun_win

最新推荐文章于 2025-07-17 21:12:39 发布

阅读量956

点赞数

分类专栏： C++/VC 文章标签： null exception class 语言 dll mfc

C++/VC 专栏收录该内容

12 篇文章

订阅专栏

将近一年的时间，我一直在用VC的ATL开发COM组件，其间遇到过不少的障碍，经过努力，大多数已经解决。在这这个过程中，积累下一了点经验，现在写下来，还是为了那两个目的：整理存档；和大家共享一些心得。

1. ProgID在哪里

这是我刚会用ATL向导时遇到的第一个问题。想修改ProgID却怎么也找不到。原来它躲在和组件同名的.rgs文件里，rgs是组件注册的脚本文件，当你用 Regsvr32.exe注册组件时，组件内部便是调用了这个文件。rgs文件是以资源的形式存于DLL内的。

2．手工添加一个方法，该修改哪些地方。

假设组件类名叫CObj,接口叫IObj，要加入的方法是Open。首先在IDL文件中找到接口IObj的定义，在其中加入如下方法定义：

[id(2), helpstring("method Open")] HRESULT Open([out,retval] VARIANT_BOOL *ret);

注意：id中的数字不要和已经存在的id重复

其次，在CObj的类定义头文件中加入如下成员函数声明：

public:

STDMETHOD(Open)(VARIANT_BOOL *ret);

最后，在CObj类的实现Cpp文件中加入函数的实现：

STDMETHODIMP Open(VARIANT_BOOL *ret)

{

*ret = VARAINT_TRUE;

return S_OK;

}

3. 多用断言帮助调试

COM组件是一个个独立的实体，它并不知道调用它的环境，也不知道调用者是否按开发者的约定来调用它。所以应该多用ATLASSERT来设置检查点，以便于调试。例如一个数据库连接组件，在Open方法里就首先要用断言检查ConnectionString属性是否被赋值：

ATLASSERT(m_ConnStr != NULL);

断言后应该紧跟着写错误处理程序，因为在Release版中，断言全部无效了，你的错误处理代码就该发挥作用了。

if(m_ConnStr == NULL)

return E_FAIL;

断言失败到底要不要处呢？这里提供一种判断原则：你开发的COM是一个自己的软件内部使用的COM，也就是客户端和COM都是你一人或开发组内部开发时，可以不处理断言失败，而去检查使断言失败的客户端的代码是否不完善；当你写的COM是要提交给”别人”使用时就要处理断言失败。

4. 写一些可以”偷懒”的宏。

如果一个组件有很多的属性，而对属性的处理不过是直接存取成员变量，写很多的get、put函数有点烦人。这些函数体看起来几乎一样，只是存取的数据类型不同：

get函数体： *pVal = m_SomeMemberVar;

put函数体： m_SomeMemberVar = newVal;

我们不妨写一组宏来处理这种无聊的工作。受ATL中Copy策略类的启发，我写了下的宏：

//实现属性写操作的通用宏

#define PROP_PUT_IMPL(Name,Type) /

STDMETHOD(put_##Name)(Type newVal) /

{ /

m_##Name = newVal; /

return S_OK; /

}

//实现属性读操作的通用宏

#define PROP_GET_IMPL(Name,Type,CopyAdapter) /

STDMETHOD(get_##Name)(Type* pVal) /

{ /

CopyAdapter::destroy(pVal); /

Type src = m_##Name; /

return CopyAdapter::copy(pVal, &src); /

}

//实现读写属性的通用宏

#define PROP_IMPL(Name,Type,CopyAdapter) /

PROP_PUT_IMPL(Name,Type) /

PROP_GET_IMPL(Name,Type,CopyAdapter)

使用这个宏的前提是保存属性的成员函数的命名必须是:”m_属性名”这样的形式，如有一个读写属性 Name，类型为BSTR，我可以在对像类中这样实现它

class ATL_NO_VTABLE CObj

{

… …

public:

PROP_IMPL(Name,BSTR,CopyBSTR)

private:

CComBSTR m_Name;
}

CopyBSTR是我写的一个Copy策略类，如下：

class CopyBSTR

{

public:

static HRESULT copy(BSTR* p1, BSTR* p2)

{

ATLASSERT(p2 != NULL);

if(p2 == NULL)

return E_POINTER;

CComBSTR bstrTemp = *p2;

return bstrTemp.CopyTo(p1);

}

static void init(BSTR* str) {}

static void destroy(BSTR* str) {SysFreeString(*str);}

};

实现只读属性也很简单：

……

public:

PROP_GET_IMPL(Name,BSTR,CopyBSTR)

private:

m_Name;

实现一些常用类型的写法如下：

PROP_IMPL(PropName,long,_Copy<long>)

PROP_IMPL(PropName,short,_Copy<short>)

PROP_IMPL(PropName,VARAINT_BOOL,_Copy<VARAINT_BOOL>)

PROP_IMPL(PropName,IDispatch*,_CopyInterface<IDispatch*>)

PROP_IMPL(PropName,BSTR,CopyBSTR)

使用这个宏还有个附加的好处：定义的都是inline函数，效率会比向导生成的函数体好。

还有一种代码段是很常用的，形如：

HRESULT hr = Obj->MethodCall();

if(FAILED(hr))

return hr;

我们可以定义这样的宏来代替它：

#define RET_ERR_IF_FAIL(exp) /

do { /

HRESULT __hr = (exp); /

if(FAILED(hr) return hr; /

} while(false)

然后这样使用：

RET_ERR_IF_FAIL(Obj->MethodCall());

RET_ERR_IF_FAIL(Obj->MethodCall2());

怎么样，代码整洁多了吧。

5.BSTR的使用

初学COM肯定要在BSTR上栽跟头，分配、释放弄得一头雾水，内存泄露在所难免。劝大家尽量不要直接使用BSTR，用封装类_bstr_t和CComBSTR取而代之。_bstr_t是一个类，它是 MS对ANSI C++的扩展，有了它，你可以在SDK方式中（非MFC、ATL）方便的使用BSTR类型。CComBSTR是ATL中对BSTR的封装。用ATL开发时，一般情况下可以用CComBSTR类。在属性的读取函数中，可以用CComBSTR的CopyTo方法返回一个BSTR。CComBSTR重载了取地址运算符&,对CComBSTR取地址等于对它内部的BSTR取地址，这样，CComBSTR也可以用在方法的out,retval类型参数上，例如：

有某COM类的某方法定义如下：

HRESULT GetUserName([in]BSTR UserID,[out,retval]BSTR *UserName);

此方法内部可如下实现返回UserName的代码：

……

m_UserName.CopyTo(UserName);//m_UserName为成员变量，类型为CComBSTR

而此COM的客户端调用GetUserName时，也可以用CComBSTR类型变量来得到UserName.

……

CComBSTR bstrUserID(L”001”),bstrUserName;

Obj->GetUserName(bstrUserID,&bstrUserName);

不管是方法GetUserName内部还是客户端，都能够正确的自动的分配、释放内存。只有一种情况例外，那就是连续使用一个CComBSTR变量作为输出参数的实参时，如果处理不当会产生内存泄露。如：

CComBSTR bstrFieldName,bstrFieldValue;

bstrFieldName = L”usr_id”;

RecordsetObj->GetFieldValueAsString(bstrFieldName,&bstrFieldValue);

m_UserID = bstrFieldValue;

bstrFieldName = L”usr_name”;

RecordsetObj->GetFieldValueAsString(bstrFieldName,&bstrFieldValue); //如果方法内部实现直接覆盖&bstrFieldValue指针，则bstr上次的值会丢失。如果内部是用的CComBSTR.CopyTo则不会。

_bstr_t类型不是不好，但我们总是在迫不得以时才会用它，也就是用#import预编译指令导入一个COM的封装类时。用import导入的封装类只用_bstr_t类型作为BSTR参数类型，而在CComBSTR、_bstr_t、BSTR之间来回转换也是顶麻烦的事。于是我仿照CAdapt类写了一个CBSTRAdapt来自动完成转换的工作。

class CBSTRAdapt

{

_bstr_t m_str;

public:

CBSTRAdapt(const _bstr_t& str)

{

m_str = str;

}

CBSTRAdapt(const BSTR str)

{

m_str = str;

}

CBSTRAdapt(const CComBSTR& str)

{

m_str = str.m_str;

}

operator BSTR()

{

return m_str.GetBSTR();

}

operator _bstr_t()

{

return m_str;

}

operator CComBSTR()

{

return CComBSTR(m_str.GetBSTR());

}

};

它的主要用途是完成从CComBSTR到_bstr_t的转换。

例如有要调用如下方法：

bool IsLogin(_bstr_t UserID);

调用代码如下：

CComBSTR bstrUserID(L”007”);

if(Obj->IsLogin(CBSTRAdapt(bstrUserID))

{

……

}

5.自定义错误代码？HRESULT？异常？

COM中的出错处理可以有多种选择，比如用方法的[out,retval]参数返回自定义的错误代码；或返回标准的以及自定义的HRESULT值；抛出异常也是一种选择。采用哪种方法要根据实际情况而定。

返回自定义错误代码是一种源自C语言结构化设计的传统方法，它放弃了C++以及COM的出错处理机制，采用自建的处理方法。代码上少不了要写很多的switch -case语句以捕捉错误代码进行处理。它的缺点是最外层代码要想得到最内层的错误的话，则中间层就必须如实的返回内层的出错代码，这样一层层的”抄送” 给最外层。带来的负作用就是灵活性非常差。

异常(exception)可以解决这个问题。但在COM规范里规定，一个COM组件不能让任何异常逃脱到这个COM之外，原因是你不知道调用这个COM的客户端语言是否支持异常机制，它能不能捕获(catch)到这个异常。规定是死的，人的活的。如果客户端缺定也是C++编写的，并且你也不需要编写那么”规范”的COM，而只要实用就行，那么从COM里抛出异常，客户端来捕获又何妨？不过，这种”玩法”最好仅在进程内DLL中使用，跨进程、跨机器的异常能不能被正常捕获，COM规范里可没承诺什么，本来你就没用COM的推荐方法嘛。

那什么是COM的推荐方法，答案是HRESULT。我们可以返回一个HRESULT值表示某种错误。很多情况下，我们都懒得去查预定义的HRESULT值，更不愿意自已定义HRESULT了，于是几乎所有的方法都是返回S_OK或E_FAIL。其实32位长的HRESULT给我们留出了充足的空间来定义自已的错误码。你可以把HRESULT值定义在IDL文件中，这样当客户端#import这个COM时，也会把定义自动加到*.tlh文件中，无需附加的.h文件声明：

cpp_quote("//自定义错误码")

cpp_quote("#define E_IDNOTFOUND 0x8000F001")

cpp_quote("#define E_IDEXIST 0x8000F002")

cpp_quote("#define E_IDREQUIRED 0x8000F003")

客户端处理HRESULT值分为两种情况。如果你用VC写客户端，用#import预编译指令生成了COM的智能封装，那么这个封装会自动把错误的返回码转成一个异常抛出。如下面是#import生成的封装代码：

inline _variant_t IContext::GetContextValue ( _bstr_t PropName ) {

VARIANT _result;

VariantInit(&_result);

HRESULT _hr = get_ContextValue(PropName, &_result); //调用真正的方法

if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this)); //如果返回一个ERROR值，_com_issue_errorex就抛出异常

return _variant_t(_result, false);

}