Windows COM服务器是否必须为[out]参数调用SysFreeString()?

Windows COM服务器是否必须为[out]参数调用SysFreeString()?,windows,visual-c++,com,interop,Windows,Visual C++,Com,Interop,我们有以下接口: [object, uuid("uuidhere"), dual ] interface IInterface : IDispatch { [id(1), propget] HRESULT CoolProperty( [out, retval] BSTR* result ); } 现在有个小问题。一方面,参数是“out”,因此任何值都可以作为输入传递,只有在成功返回时,参数才有效。另一方面,很多页面都链接到一个函数,它基本上说(最后一段),如果传递了一个BSTR*函数,

我们有以下接口:

[object, uuid("uuidhere"), dual ]
interface IInterface : IDispatch
{
    [id(1), propget] HRESULT CoolProperty( [out, retval] BSTR* result );
}
现在有个小问题。一方面,参数是“out”,因此任何值都可以作为输入传递,只有在成功返回时,参数才有效。另一方面,很多页面都链接到一个函数,它基本上说(最后一段),如果传递了一个
BSTR*
函数,它必须在分配新字符串之前释放该字符串

那太可怕了。如果这篇文章是正确的,则意味着所有调用方都必须通过有效的BSTR(可能是空的BSTR),否则BSTR传递可能会泄漏。如果调用者传递了一个随机值,而被调用者试图调用
SysFreeString()
,那么它将运行到未定义的行为中,因此约定是至关重要的

那么
[out]
属性的意义是什么?在这种情况下,
[in,out]
[out]
之间有什么区别


那篇文章对吗?在分配新的BSTR参数之前,是否需要释放已传递的BSTR
[out]
参数?

您应该期望客户端遵守合同,遵守[out]属性,而不是传递需要释放的初始化BSTR。重复检查并预期为NULL是不是好的,契约不要求客户端传递指向初始化内存位置的指针。您通常会得到一个指向在堆栈帧上分配的BSTR变量的指针。它可能包含随机垃圾,只有防御性程序员才会将其设置为NULL

它在其他方面与OLE自动化不兼容。在这种情况下,只有[out,retval]和[in,out]是有效的,这无疑是为了避免这种特殊的陷阱。

被调用方永远不应该释放出指针,因此,依我看,您最好遵守规范

最好的