wchar_tって… - ntnekの日記

つれづれと。

仕事で使うプログラムで、日本語使うのでwstringつかってちゃちゃっとWindowsで作ったわけですよ。んで、FreeBSD 5.4 + gcc-3.4な環境に持っていってビルドして実行させたら駄目なわけですよ。
最初にずっこけたのは locale が "C" しかサポートしてないことなんだけど。そーすると日本語のワイド文字列リテラルが書けませんやん？

で、何を思ったかBSDのlibcのlocale周りを漁ってみたりしたわけですよ。CitrusのアーカイブからLi18nな人たちとのやり取りとかも読んで。仕事と無関係なことで丸一日費やしちゃってごめんなさい＞課長

で、結論として、

wchar_tの実装は環境によってまちまち。つまり、
- Win32ではUCS-2(UTF-16)
- Linuxなどの__STDC_ISO_10646__な環境ではUCS-4
- BSD(Citrus)は「ロケール依存の4bytes」
- それ以外？
GCCではワイド文字列リテラルはまともに使えない*1
つまり、mbstowcsしたからと言って意図どおりマルチバイト文字列がワイド文字列になったりしません。
なんで諦めて、以下のようにすべし：
- ソースコードにはすべてマルチバイト文字列リテラルとして記述し、記述したそばから wstring に変換する
- wstringへの変換は、非win32環境ではiconvに頼る。
  - LinuxではUCS-4に変換してmemcpy
  - FreeBSDでは変換先コードを"wchar_t"に指定

とゆーことにしました。強引極まりない。

で、こゆことしていて思ったのは、「文字のない文字列ってできんのかな」とゆーこと。
例えば…

char raw_str[] = "日本語ですねん。";
mbstring str(raw_str, "SJIS");
mbchar c = str[3];

としたとき、この c というのは[raw_str + 6, raw_str + 8)を指すイテレータのペアとするわけ。

そもそもwchar_tが欲しいのは可変長文字を扱うのが面倒くさいからなわけですよ。そこを隠蔽できるなら、やり方はなんでもよいわけで。

mbcharのoperator overloadingやctype関連さえちゃんと揃えれば、余計な、変換とか、可変長とか、余計なことを気にせずにお気楽な文字列操作コードが書けたりしないだろーか、と。

…無駄に重い？

*1:--enable-c-mbcharは試してません