[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unicode, or die

>> From: "T.SHIOZAKI" <AoiMoe@imou.to>
>> それなら、wchar_t は現状のままで放っておいて、これとは独立な Unicode
>> 前提の API セットを作ったほうが、互換性の観点から正しいことは彼らも
>> 分かってるはずなのだけど、何でそうしないのでしょうね。

まったく同感です。

>>>>> On Mon, 15 May 2000 17:36:25 +0900,
	Hideki Hiura <hiura@eng.sun.com> said:
>> 互換性を考えたら、なし崩し的に互換性のない wchar_t の使い方をされるよりも、

> もう一つ私の言葉が足りなかったのですが、現実として glibc では、wchar_t 
> が既にUCS-4/UTF-32 に固定されてしまっていて、すべての locale が、Tru64
> UNIX で言う、@ucs4 付きの locale と同じ状態にあります。

>> ISO C locale まわりを全部「obsoleted」にして、使わないよう勧告をしてくれた
>> 方がはるかにマシなんですが、時間なくてそこのところを質問しそびれたのが残念。

> この場を借りてお答えしますと、それも一つの選択肢として残っていないわけ
> ではありません。

では、その選択肢を提言していただけないでしょうか？

> wcahr_t が UCS-4/UTF-32固定であることを認めるからと言って、CSI を捨て
> ることになるのか、と言うと、現実的には、そうとも言えないところがあると
> 考えます。CSI compliant な system/appliaction では、wchar_t の 
> representation が変わっても困らないはずです。

これは誤りでしょう。

wchar_t == Unicode を仮定したコードを許容すると、従来の
wchar_t != Unicode であるシステム上では、そのようなコードは動作しなく
なります。

確かに
	CSI compliant な system/appliaction では、wchar_t の 
	representation が変わっても困らない
は真ですが
	wchar_t の representation として Unicode を仮定した
	プログラムが、CSI compliant な system/appliaction で
	動くか？
は偽です。

wchar_t が、 UCS-4/UTF-32固定であるシステムが存在しても、まったく
問題ありません。しかし、
	wchar_t が UCS-4/UTF-32固定であるという仮定を、
	アプリケーションやライブラリに対して許す
ということは、すなわち
	CSI を捨てる
ということです。

> ただ、wcahr_t が UCS-4/UTF-32 であることを無条件に保証するかのように
> 聞こえる私の発言は、たしかに舌足らずでした。

「wchar_t がUCS-4/UTF-32 であることは保証されないので、それに依存して
プログラムを作成してはいけない。そういうプログラムやライブラリは 
portable ではない」と明言しない限り、Free Standard Group は CSI を
捨てたと見なされるべきでは？
--
soda