3

2 つのサードパーティ ライブラリを使用するプロジェクトがあり、どちらもヘッダー ファイルで TCHAR を使用します。残念ながら、1 つのライブラリはマルチバイトとしてコンパイルされ (ライブラリ a と呼びます)、もう 1 つのライブラリは Unicode としてコンパイルされます (ライブラリ b と呼びます)。

今私が理解している方法は、プリコンパイラによって TCHAR がビルドオプションに応じて wchar または char に置き換えられるということです。そのため、ライブラリ a がコンパイルされたとき、TCHAR 型のパラメータを受け取るメソッドは char 型のパラメータを期待するように設定され、ライブラリ b のメソッドは wchar 型のパラメータを期待するように設定されています。

残念ながら、消費するアプリケーションも文字セットを選択する必要があります。Unicode を選択すると、ライブラリ a にインクルードしたヘッダー ファイルは、メソッドが wchar を必要としていることを示します。これは、ヘッダー内の TCHAR をコンパイルすると wchar として解釈されるためです。これには、構造内で定義された TCHARS が含まれます。この動作を実際に確認しました。TCHAR バッファを割り当てて渡すと、wchar バッファがマルチバイト データでいっぱいになるため、ガベージが返されます。

私の質問は次のとおりです。これらのライブラリの両方を同じアプリケーションで使用するクリーンな方法はありますか? これらのライブラリの使用方法に何か問題があるのでしょうか?

4

3 に答える 3

4

これらのライブラリのいずれかであまり多くのクラス/関数を使用していないと仮定すると、ライブラリの1つを完全にラップします。アプリでmbcを使用し、ライブラリb（unicode）をラップすることにした場合、wchar_t代わりにラッパーヘッダーファイルを使用できるTCHARため、＃defineはインターフェイスに影響しません。ライブラリbのヘッダーを#includeするラッパーのcppファイル内で、TCHARライブラリbと一致するように#defineします。ラッパー以外のコードがライブラリを表示できないようにする必要がありますb。

これらのライブラリの両方で複数のクラス/関数を使用している場合、ラッパーコードを維持することはすぐにそれ自体の問題になります。

于 2009-05-02T03:04:40.223 に答える
1

Shing Yipが提案したように、独自の API で違いをラップすることをお勧めします。これにより、ソース コードがソース コードから独立します。

ラッピング API は、文字をユーザーのエンコーディングからライブラリのエンコーディングに変換する必要があります。Windowsでは、WideCharToMultiByteなどと呼ばれる関数があります。

于 2009-05-02T04:29:54.137 に答える
0

最善の選択肢は、ライブラリaまたはライブラリb（この例ではライブラリaと呼びます）のいずれかの方法を選択することだと思います。そして、ライブラリbヘッダーファイルをインクルードするときは、ライブラリbがコンパイルされたものが何であれ＃define /＃undefであることを確認してください。次に、ライブラリaとライブラリbが同じデータを使用する場合は、必ずそれらを変換する必要があります。

同じようにコンパイルできれば本当に最高です。そうでなければ、それは非常に厄介になるでしょう。

于 2009-05-02T01:28:43.777 に答える