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

Question

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

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

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

安全还是依赖？

在这个代码示例中，它的字符串（从随机源中获取的代码）：

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

我很困惑何时使用在讨论COM时出现的所有编组，内存边界等等。

数据缓冲区（byte *）怎么样？

Answer 1

这取决于呼叫者呼叫您的上下文。首先，如果您使用非自动化类型，则不会自动执行编组。因此，您最终必须编写自己的封送程序来跨进程边界移动wchar_t *。

那就是说，没有规则说你不能在COM接口中传递wchar_t *。有许多COM接口可以传递自定义类型（结构，指向结构，回调等），而这些只是你的需求。

在你的界面中，如果你使用WCHAR字符串，我会以这种方式声明SetAudioLanguageOrder：

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

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

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

Answer 2

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

Answer 3

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

与COM不一样 - 你可能想要在代理过程中创建一个out-proc服务器或使用你的进程内服务器，然后你需要编组 - 一种在进程或线程之间传输数据的中间件机制 - 上班。除非您使用诸如size_is之类的MIDL属性来指定正确的数组大小，否则该机制将不知道字符串的大小。使用这些属性将需要为每个数组添加一个额外的参数 - 这会使接口变得复杂，并且在处理数据时需要格外小心。

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