COM 接口(interface)中的 WCHAR 是好事吗？
我一直在互联网上寻找这个问题的答案，但没有任何结果。
基本上应该在 COM 中使用 char*/wchar* 还是应该使用 BSTR 代替？
它是安全的还是取决于它？
在此代码示例中，它的字符串(从随机来源获取的代码):
STDMETHOD(SetAudioLanguageOrder(WCHAR *nValue)) = 0;
STDMETHOD_(WCHAR *, GetAudioLanguageOrder()) = 0;
当谈到 COM 时，我对何时使用所有编码、内存边界等内容感到困惑。
数据缓冲区(字节*)呢？
最佳答案
这取决于调用者调用您的上下文。首先，如果您使用非自动化类型，则不会自动为您执行编码。因此，您最终将不得不编写自己的编码(marshal)拆收器来跨进程边界移动 wchar_t*。
也就是说，没有规定不能在 COM 接口(interface)中传递 wchar_t*。有许多 COM 接口(interface)可以传递自定义类型(结构、指向结构的指针、回调等)，这完全取决于您的需求。
在您的界面中，如果您确实使用 WCHAR 字符串，我会这样声明 SetAudioLanguageOrder:
STDMETHOD(SetAudioLanguageOrder(const WCHAR *nValue)) = 0;
这使得更清楚谁(不)应该释放字符串，并提供更多关于如何处理字符串的上下文(不鼓励调用者修改字符串，尽管调用者如果想编写错误的代码当然可以强制执行该行为)。
GetAudioLanguageOrder 调用没问题，但现在的问题是:谁释放返回的字符串，应该如何释放？通过免费(...)？还是 C++ 删除[]？如果您使用 BSTR，那么您知道 - 使用 SysFreeString。这是使用 BSTR 而不是 WCHAR 字符串的部分原因。
关于com - COM 接口(interface)中的 WCHAR 是好事吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5956072/