4

Visual C++ プロジェクトを GCC に移植するときに、wchar_t データ型がデフォルトで 4 バイトの UTF-32 であることがわかりました。コンパイラ オプションでこれをオーバーライドできますが、4 バイト幅の文字列を想定しているため、RTL の wcs* (wcslen、wcscmp など) の部分全体が使用できなくなります。

今のところ、これらの関数の 5 ~ 6 個をゼロから再実装し、実装を #define しました。しかし、より洗練されたオプションがありますか?たとえば、2 バイトの wchar-t を使用して GCC RTL をビルドし、リンクされる?

私が求めている GCC の特定のフレーバーは、Mac OS X 上の Xcode、Cygwin、および Debian Linux Etch に付属するものです。

4

4 に答える 4

2

しかし、より洗練されたオプションはありますか? たとえば、2 バイトの wchar-t を使用して GCC RTL をビルドし、リンクされるのを待っていますか?

いいえ。これはプラットフォーム固有の問題であり、GCC の問題ではありません。

つまり、Linux プラットフォームの ABIwchar_tは 32 ビット幅を指定しているため、まったく新しいライブラリ (ICU が一般的な選択肢です) を使用するか、コードを移植して 4 バイトwchar_tの s を処理する必要があります。リンクする可能性のあるすべてのライブラリも 4 バイトを想定しておりwchar_t、GCC の を使用する-fshort-wchar壊れます。

しかし、特に Linux では、ほぼすべての人がすべてのマルチバイト エンコーディングを UTF-8 で標準化しています。

于 2010-05-07T17:59:39.473 に答える
1

ICU図書館を見てください。UTF-16 API を備えたポータブル ライブラリです。

于 2010-05-07T17:31:38.683 に答える
1

お気づきのとおり、 wchar_t は実装定義です。そのデータ型で作業を移植する方法はありません。

Linux システムは一般に、UCS-2 の大失敗全体がそれほど素晴らしいアイデアではないと宣言された後、後で Unicode サポートを取得し、エンコーディングとして UTF-8 を使用するという利点がありました。すべてのシステム API は引き続き char* で動作し、Unicode セーフです。

あなたの最善の策は、これを管理するライブラリを使用することです:Qt、ICUなど.

cygwin には 2 バイトの wchar_t があり、Windows とのメッシュ化を容易にすることに注意してください。

于 2010-05-07T17:58:48.153 に答える
0

より一般的な wcs* 関数の 5 ~ 6 個を再実装し、実装を #define しました。

于 2010-10-12T03:41:55.510 に答える