- 396 名前：マカース受信中 mailto:sage [02/11/26 13:14 ID:6Jv4mTS/.net]
- ライブラリ群の協調の為にwchar_t = UCS4として生触りしたいのであれば
#define __STDC_ISO_10646__で既存のwchar_t, wcslen, wcscmp, wcswidthを乗っ取るなんて
ギャングな方法でなく、ucs4_tによって内部表現がUCS4であることの保証、
そしてucs4len, ucs4cmp, ucs4widthを実装して、な方法が正しい方法でしょう。
むしろ変換なんてセコイこと言わずに、multibyteは全てutf8と仮定して
utf8len, utf8cmp, utf8widthを実装して、既存のctypeは全廃したほうがlibcもすっきりしますね。
では、ロードマップとしては5年後までに既存のctypeを全廃ということで。
…ネタはさておき。
ああ、でもちょっとマジレスする時間が無かったり。
ちゃんとした反論はもうちょっと待ってね>>391
軽く>>389を補足しておけば、
libcの持つ情報の提供という点では、UCS4 hardwire vs is???/nl_langinfoの戦いは
例えはロケールDBがOracleだったとしたら(w
SQLを叩くか(直値)、ストアドプロシージャを使うか(手続)とか程度の
不毛な議論にしかならないと思います。
DBの中身が同じであれば結果に差異はでないはず。
ただし、文字とは何か？を考えるとUCS4 hardwireでは失うものは多いと。
樋浦さんの言葉を借りれば「Unicodeの表現能力の限界」っすね。
|
 |
