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++ 中，通常使用以 null 结尾的字符串，并且您经常在一个进程中使用它们——被调用者访问的数据与调用者准备和以 null 结尾的数据完全相同。
与 COM 不同 - 您可能希望创建一个进程外服务器或在代理进程中使用进程内服务器，然后您需要编组（一种在进程或线程之间传输该数据的中间件机制）才能工作。该机制不会知道字符串的大小，除非您使用 MIDL 属性之一，例如size_is指定正确的数组大小。使用这些属性将需要为每个数组添加一个额外的参数——这会使界面复杂化，并且在处理数据时需要格外小心。
也就是说，在大多数情况下，您只需使用BSTRs 即可获得更流畅的界面。