3

BSTRCOM関数など、いくつかの特定の用途を持つこの奇妙なWindowsデータ型です。MSDN によると、これにはWCHAR文字列と、長さ記述子などのその他の要素が含まれています。Windows は、カプセル化された_bstr_t クラスを提供してくれますBSTR。割り当てと割り当て解除を処理し、いくつかの追加機能を提供します。これには、 を受け取るコンストラクタと を受け取るコンストラクタを含む4 つのコンストラクタchar*がありwchar_t*ます。前者についての MSDN の説明: 「_bstr_t呼び出しSysAllocStringて新しいBSTRオブジェクトを作成し、それをカプセル化することによってオブジェクトを構築します。このコンストラクターは、最初にマルチバイトから Unicode への変換を実行します。」

また、文字列へのポインターを 、 、 のいずれかとして抽出できる演算子もあり、それらがヌルで終了していることは確かです。これはすばらしいことです。char*const char*wchar_t*

マルチバイトと Unicode の間で変換する方法について、しばらく読んでみました。また、エンコーディングが異なる可能性があるため、 and の使用方法mbstowcsとwcstomb、 andMultiByteToWideCharのほうが優れていることについての多くの話を見てきました。WideCharToMultiByteそれはすべて頭痛の種のように思えるので、を構築して操作を使用して文字列にアクセスできるかどうか疑問に思ってい_bstr_tます。

char* multi = "asdf";
_bstr_t bs = _bstr_t(mb);
wchar_t* wide = (wchar_t*)bs; // assume read-only

これに対する私の直感的な答えは、Windowsが舞台裏で何をしているのかわからないということだと思います。そのため、 / ではなく / (私は本当に / を意味していると思います) の使用に問題がある場合、リスクをmbstowcs冒すwcstombべきmbstowcs_sではありません。 Windowsがそれらを使用する可能性があります。（ここでは「コードページ」を指定していないので、後者を使用していないことはほぼ確実です.さまざまなエンコーディングなどのすべてを実際に把握していますが、それはまったく別の質問であり、インターネット全体で対処されているようです.wcstomb_sMultiByteToWideCharWideCharToMultiBytembstowcs_swcstomb_s

すっごく、その潜在的な懸念は別として、これを行うことに何か問題はありますか?

4

1 に答える 1

2

プロダクションコードでは、次の使用_bstr_t::_bstr_t(const char*)は必ずしも良い考えではありません。

_bstr_tを呼び出しSysAllocStringて新しいBSTRオブジェクトを作成し、それをカプセル化して、オブジェクトを構築します。このコンストラクターは、最初にマルチバイトから Unicode への変換を実行します。が大きすぎると、スタックオーバーフローエラーが発生する可能性があります。s2このような状況では、 withに変換してchar*からコンストラクターを呼び出します。wchar_tMultiByteToWideCharwchar_t *

それに加えて、_bstr_t::operator wchar_t*() const throw()ほとんど役に立たないようです。これは構造体メンバーの抽出のためだけのものであるため、次のように制限されますconst。

これらの演算子を使用して、カプセル化された Unicode またはマルチバイト BSTR オブジェクトへの生のポインターを抽出できます。演算子は実際の内部バッファーへのポインターを返すため、結果の文字列は変更できません。

s_bstr_tをカプセル化するための単なるヘルパー オブジェクトBSTRであり、平凡なものです。MultiByteToWideCharandを使用した変換WideCharToMultiByteは、複数の理由から、はるかに優れた選択です。

  • クラッシュする可能性ははるかに低くなります。
  • const独自のバッファを提供するため、見返りにバッファを取得しません。
  • これらの関数の名前は自己記述的です。関連のない型のコンストラクターおよびキャスト演算子による変換はできません。
于 2013-01-14T22:44:47.267 に答える