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

Question

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

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

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

私の質問は次のとおりです。同じアプリケーションでこれらのライブラリを両方とも使用するきれいな方法はありますか？私はおそらく私がこれらのライブラリをどのように使っているかに何か間違っていますか？

Answer 1

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

これらのライブラリの両方でいくつかのクラス/機能を使用している場合は、ラッパーコードを維持することがすぐに独自の問題になります。

Answer 2

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

同じ方法でコンパイルすることができれば、本当にベストだろう。それ以外の場合は非常に乱雑になるでしょう。

Answer 3

Shing Yipと表示されているように、独自のAPIで違いをよりよくラップしてください。これはあなたのソースコードを独立させます。

ラッピングAPIは、文字をエンコーディングからライブラリに変換する必要があります。窓では、私はWideCharToMultiByteと呼ばれる機能を持っています。