COM 接口中的 WCHAR 是好事吗？
我一直在互联网上搜索这个问题的答案，但没有任何结果。
基本上应该在 COM 中使用 char* / wchar* 还是应该使用 BSTR 代替？
它是安全的还是取决于它？
在此代码示例中，它的字符串（从随机来源获取的代码）：
STDMETHOD(SetAudioLanguageOrder(WCHAR *nValue)) = 0;
STDMETHOD_(WCHAR *, GetAudioLanguageOrder()) = 0;
我很困惑何时使用所有编组、内存边界等在谈论 COM 时出现的内容。
数据缓冲区（字节*）呢？
【问题讨论】：
这取决于呼叫者呼叫您的上下文。首先，如果您使用非自动化类型，则不会自动为您执行编组。因此，您最终将不得不编写自己的封送处理程序来跨进程边界移动 wchar_t*。
也就是说，没有规定不能在 COM 接口中传递 wchar_t*。有许多 COM 接口可以传递自定义类型（结构体、结构体指针、回调等），这完全取决于您的需求。
在您的界面中，如果您确实使用 WCHAR 字符串，我会这样声明 SetAudioLanguageOrder：
STDMETHOD(SetAudioLanguageOrder(const WCHAR *nValue)) = 0;
这使得谁（不）应该释放字符串更清楚，并提供更多关于如何处理字符串的上下文（不鼓励调用者修改字符串，尽管调用者当然可以强制执行该行为，如果他们愿意写不好的代码）。
GetAudioLanguageOrder 调用没问题，但现在的问题是：谁释放了返回的字符串，应该如何释放它？通过免费（...）？还是 C++ 删除[]？如果您使用 BSTR，那么您知道 - 使用 SysFreeString。这就是使用 BSTR 而不是 WCHAR 字符串的部分原因。
【讨论】：
如果您要支持双接口和 C++ 以外的客户端，请使用 BSTR。如果所有调用者都是 C++，那么 WCHAR* 就可以了。
【讨论】：
您必须能够以一种或另一种方式知道该数组的长度。在 C 或 C++ 中，通常使用空终止字符串，并且您经常在一个进程中使用它们 - 被调用者访问的数据与调用者准备和空终止的数据完全相同。
与 COM 不同 - 您可能希望创建一个进程外服务器或在代理进程中使用进程内服务器，然后您需要编组 - 一种在进程或线程之间传输该数据的中间件机制 -去工作。该机制不会知道字符串的大小，除非您使用诸如size_is 之类的 MIDL 属性之一来指定正确的数组大小。使用这些属性需要为每个数组添加一个额外的参数——这会使界面复杂化，并且在处理数据时需要格外小心。
也就是说，在大多数情况下，您只需使用BSTRs 即可获得更流畅的界面。
【讨论】：