Com 谁负责清理[输入]变量参数？

在具有

[In]VARIANT param

的接口中，调用方是否拥有复制到它的变量？被调用者是否应调用该值的

VariantClear

（或ATL

CComVariant:：Attach

）以确保该值已清除？是否记录了自动化内存管理规则（添加到）

我知道

[in]VARIANT*param

是调用者拥有的指针，但是

[in]VARIANT param

是复制到被调用者的结构，所以有点奇怪。如果所有权没有转移，那么为什么会有人使用

[in]VARIANT param

定义接口呢？在stdcall x86和x86_64调用约定中，它从不适合于寄存器，因此它并不比VARIANT*param更有效，因此它似乎没有什么意义

---

我这样问是因为我想知道如何实现。

是的，

[in]

参数由调用者拥有，无论是

VARIANT

类型还是其他类型。你还需要什么澄清？我不知道你为什么觉得

[in]VARIANT

与

[in]IUnknown*

有根本的不同，比如说，COM接口指针也被复制了-你认为这一定意味着它的所有权被转移了吗？我想我是很谨慎的b/c 1）我不知道自动化的所有例外情况（例如，SysFreeString而不是CoTaskMemFree），2）我不知道为什么有人会使用

[in]VARIANT

vs

[in]VARIANT*

，3）如果每个变量在超出范围之前都必须进行变量清理，那么会简单得多。但是如果你简单地复制一个变量，现在你不得不担心拥有它的数据的变量和不拥有它的数据的变量，4）这是我第一次在COM中看到传递值结构。如果你通过值传递一个变量，并且你在变量中传递的内容可以适应它（整数、浮点数、日期等等），这样，您就不需要在堆上进行任何额外的分配/释放（所有操作都发生在堆栈上——至少在运行客户端和服务器inproc时是这样）。我想这是一种设计选择。SDK中有很多这样定义的接口（例如mshtml.h/IE）。Re:

SysFreeString

而不是

CoTaskMemFree

——那么您是否同样担心BSTR参数中的

，声称如果每个
BSTR
指针在超出范围之前都是
SysFreeString
的话会简单得多，或者想知道为什么接口不使用
[in]BSTR*
？在浅层复制时，将拥有数据的
BSTR
指针与不拥有数据的指针区分开来是否有困难？将
VARIANT
视为自动化的基本类型，类似于
BSTR
或
IUnknown*
。C关键字
struct
恰好用于其定义这一事实是不相关的。请注意，内存处理COM异常对管理对象生存期的一般规则没有影响。因此，尽管我同意必须了解
IUnknown:：Release
、
CoTaskMemFree
、
VariantClear
和
SysFreeString
并不是特别好，但它们的应用方式基本相同，而且从不在
[in]
参数上（除非您
IUnknown:：AddRef
使用
[in]
接口指针，当不再需要时应将其释放）。