COM インターフェイスの WCHAR は良いことですか?
私はインターネットでこの質問に対する答えを探していましたが、結果はありませんでした。
基本的に、COM で char* / wchar* を使用する必要がありますか、代わりに BSTR を使用する必要がありますか?
それは安全ですか、それとも依存していますか？
このコード例では、その文字列 (ランダム ソースから取得したコード):
STDMETHOD(SetAudioLanguageOrder(WCHAR *nValue)) = 0;
STDMETHOD_(WCHAR *, GetAudioLanguageOrder()) = 0;
COM について話すときに出てくるすべてのマーシャリング、メモリ境界などで何をいつ使用するかについて、私は混乱しています。
データ バッファ (byte*) はどうですか?
発信者があなたに電話するコンテキストによって異なります。まず、非自動化タイプを使用すると、マーシャリングは自動的に実行されません。したがって、プロセス境界を越えて wchar_t* を移動するには、独自のマーシャラーを作成する必要があります。
そうは言っても、COM インターフェイスで wchar_t* を渡してはならないというルールはありません。カスタム型 (構造体、構造体へのポインター、コールバックなど) を渡す COM インターフェイスは多数ありますが、それらはすべてユーザーのニーズに対応しています。
インターフェイスで WCHAR 文字列を使用する場合は、次のように SetAudioLanguageOrder を宣言します。
STDMETHOD(SetAudioLanguageOrder(const WCHAR *nValue)) = 0;
これにより、誰が文字列を解放する (しない) べきかが明確になり、文字列をどのように扱うかについてより多くのコンテキストが提供されます (呼び出し元は文字列を変更することを思いとどまりますが、悪いコードを書きたい場合、呼び出し元はその動作を強制できます) ）。
GetAudioLanguageOrder 呼び出しは問題ありませんが、問題は、返された文字列を誰が解放し、どのように解放する必要があるかということです。無料で(...)？または C++ 削除 []? BSTR を使用している場合は、SysFreeString を使用してください。これが、WCHAR 文字列の代わりに BSTR を使用する理由の一部です。
C++ 以外のデュアル インターフェイスとクライアントをサポートする場合は、BSTR を使用します。すべての呼び出し元が C++ の場合は、WCHAR* で問題ありません。
何らかの方法でその配列の長さを知ることができる必要があります。C または C++ では、null で終了する文字列を使用するのが一般的であり、それらを 1 つのプロセス内で使用することがよくあります。呼び出し先は、呼び出し元が準備して null で終了するのとまったく同じデータにアクセスします。
COM とは異なります。アウトプロセス サーバーを作成したり、代理プロセスでインプロセス サーバーを使用したりする場合は、マーシャリング (プロセスまたはスレッド間でそのデータを送信するミドルウェア メカニズム) が必要になる場合があります。size_isそのメカニズムは、適切な配列サイズを指定するなど、MIDL 属性の 1 つを指定しない限り、文字列のサイズを認識しません。これらの属性を使用すると、配列ごとに追加のパラメーターが必要になります。これにより、インターフェイスが複雑になり、データを処理する際に特別な注意が必要になります。
とはいえ、ほとんどの場合、単にBSTRs を使用するだけで、より流暢なインターフェイスが得られます。