6

BCB5 以降の C++Builder で開発された一連の Win32 VCL アプリケーションがあり、それらを ECB2009 または現在呼ばれているものに移植したいと考えています。

私のアプリケーションの一部は古い TNT/TMS Unicode コンポーネントを使用しているため、コード全体で AnsiString と WideString を適切に組み合わせています。新しいバージョンでは、UnicodeString と、c_str などの関数の動作を変更する多数の #define が導入されています。

必要に応じて、BCB2007 で同じコード ベースを (Unicode 以外の方法で) コンパイルして実行できるように、可能な限り下位互換性のある方法でコードを変更したいと考えています。

特に懸念される分野は次のとおりです。

  • Win32 API 関数との間で文字列を渡す
  • TXMLDocument との相互運用
  • RS232 通信などに使用される「生の」文字列。

変更をナイフ アンド フォークするのではなく、可能な限り下位互換性を維持しながら、移行を容易にするために適用できるガイドラインを探しています。

そのようなガイドラインがまだ存在しない場合は、ここで作成できますか?

4

2 に答える 2

4

最大の問題は、C++Builder 2009 と以前のバージョンとの互換性です。Unicode の違いはいくつかありますが、プロジェクト構成ファイルも変更されています。私がCodeGear フォーラムでフォローしてきた議論から、この問題にはそれほど多くの選択肢はありません。

C++Builder 2009のリリース ノートをまだ読んでいない場合は、まず最初に始めることをお勧めします。

見られる最大のものは、TCHAR マッピング (wchar または char への) です。STL 文字列の種類を使用すると、2 つのバージョン間で大きな違いはないはずなので、役立つ場合があります。マッピングは C++Builder 2007 にもありました (tchar ヘッダーを使用)。

于 2008-09-30T13:25:26.873 に答える
2

明示的にAnsiまたは明示的にUnicodeである必要のないコードについては、可能な限りSystem :: String、System :: Char、およびSystem::PChartypedefの使用を検討する必要があります。これにより、多くの移行が容易になり、以前のバージョンで機能します。

System :: StringをAPI関数に渡すときは、プロジェクトオプションの新しい「TCHARマップ先」設定を考慮する必要があります。「TCHARmapsto」が「wchar_t」に設定されているときにAnsiString::c_str（）を渡そうとした場合、または「TCHARmapsto」が「char」に設定されているときにUnicodeString:: c_str（）を渡そうとすると、適切に実行する必要があります。タイプキャスト。「TCHARmapsto」を「wchar_t」に設定している場合。技術的には、UnicodeString :: t_str（）はAPIでTCHARが行うのと同じことを行いますが、t_str（）を誤用すると非常に危険になる可能性があります（「TCHARmaps to」が「char」に設定されている場合、t_str（）はUnicodeStringのAnsiへの内部データ）。

「raw」文字列の場合は、新しいRawByteStringタイプ（推奨しませんが）、または代わりにTBytes（バイトの配列-推奨）を使用できます。そもそも文字以外のデータにはAnsi/Wide/UnicodeStringを使用しないでください。ほとんどの人は、過去のバージョンでその場しのぎのデータバッファとしてAnsiStringを使用していました。もうそれをしないでください。AnsiStringはコードページに対応しているため、これは特に重要です。したがって、予期しないときにデータが他のコードページに変換される可能性があります。

于 2009-06-04T01:08:51.157 に答える