異なる文字セットを持つライブラリのヘッダーファイルでのTCHARの処理

Question

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

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

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

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

Answer 1

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

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

Answer 2

As Shing Yip は、独自のAPIの違いをより適切にラップすることを提案しました。これにより、ソースコードは独立しています。

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

Answer 3

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

それらを同じ方法でコンパイルできると本当に良いでしょう。さもなければ、それは非常に乱雑になります。