COM中的WCHAR接口是一件好事吗？

我一直在搜索互联网上的这个问题的答案没有结果。

基本上应该在COM中使用char */wchar *还是应该使用BSTR来代替？

它安全吗？

在此代码示例其字符串（代码从随机源抓起）：

STDMETHOD(SetAudioLanguageOrder(WCHAR *nValue)) = 0; 
STDMETHOD_(WCHAR *, GetAudioLanguageOrder()) = 0;

我在什么时候使用什么与所有编组，内存边界等谈论时出现混乱COM。

什么是数据缓冲区（字节*）？

来源

2011-05-10 Carl Serl

如果您打算支持C++以外的双接口和客户端，请使用BSTR。如果所有的调用者都是C++，那么WCHAR *很好。

来源

2011-05-10 20:48:33

这取决于呼叫者会给你打电话的上下文。首先，如果您使用非自动化类型，封送处理将不会自动执行。因此，您最终必须编写自己的编组器来跨越流程边界移动wchar_t *。

也就是说，没有规则说你不能在COM接口中传递wchar_t *。有许多COM接口传递自定义类型（结构体，指向结构体，回调等的指针），这些都只是关于您的需求。

在你的界面，如果你使用WCHAR字符串，我会宣布SetAudioLanguageOrder这样：

STDMETHOD(SetAudioLanguageOrder(const WCHAR *nValue)) = 0;

这使得它更清楚谁是（不）应该释放该字符串，并提供更多的上下文如何处理字符串（不鼓励调用者修改字符串，但调用者可以强制这种行为，如果他们想写错误的代码）。

GetAudioLanguageOrder调用是可以的，但现在的问题是：谁释放返回的字符串，它应该如何释放？通过免费（...）？或者C++删除[]？如果你使用BSTR，那么你知道 - 使用SysFreeString。这是使用BSTR而不是WCHAR字符串的原因之一。

来源

2011-05-10 21:01:46

您必须能够以某种方式知道该数组的长度。在C或C++中，通常使用以空字符结尾的字符串，并且您经常在一个进程中使用它们 - 被调用程序访问与调用程序准备的相同的数据，并以null结尾。

与COM不一样 - 您可能想要创建一个out-proc服务器或在代理过程中使用您的in-proc服务器，然后您需要编组 - 一个在进程或线程之间传输数据的中间件机制- 上班。该机制不会知道字符串的大小，除非您使用MIDL属性之一（如size_is）来指定正确的数组大小。使用这些属性将需要每个阵列的额外参数 - 这会使接口复杂化，并且在处理数据时需要额外的关注。

也就是说，在大多数情况下，只需使用BSTR即可获得更流畅的界面。

来源

2011-05-11 06:10:48 sharptooth

COM中的WCHAR接口是一件好事吗？

回答

相关问题