Boost.勉強会 #6 札幌に行ってきました。hotwatermorningさんをはじめとする会場を準備してくださった皆様、ありがとうございました。

そこでの発表（char32_tとBoost.Xpressiveと at Slideshare）について、見かけた・聞いた質問に答えます。

“_t”ってtypedefした型に付けるものではないの？

wchar_tに倣ったものと思います。wchar_tもchar16_tやchar32_tもCではtypedefです。

Windows APIプログラミングはどうなる？

おそらく変わりません。TCHARがchar16_tになってTEXTマクロがuに展開されるようになるなどといったことは起こらないでしょう。そうするだけのメリットが考えられないからです。

無論、Windows APIが使わないことと、Visual C++がchar16_t/char32_tをまだ実装していないことは全然関係ない話です。

UTF‐32って使うの？

同感、外で情報のやりとりをする用途としては、たしかに不要です。しかし、1コードユニット（1要素） == 1コードポイントな固定長であるため、内部処理ではUTF‐8やUTF‐16より少しだけ便利だと思っています。もちろん、「UTF‐32は1要素 == 1文字の固定長ではありません！」そんなわけないのは私だって百も承知の上です。

なお、必ずしもchar32_tの配列（u32stringやvector<char32_t>を含む）として保持する必要はありません。O(1)のランダムアクセス性を捨てて、UTF‐8またはUTF‐16の配列（か何か）として文字列を保持すればよいのです。それをUTF‐32として読み書きするラッパさえあれば、不自由することはそうそうないと思うのです。

  • P-Stade.Ovenのutf(8|16)_decodedや、Boost.RegexのICU対応内部にあるu(8|16)_to_u32_iteratorのような「UTF‐8やUTF‐16→UTF‐32とするIteratorまたはRange」
  • utf(8|16)_encodedや、u32_to_u(8|16)_iteratorのような「UTF‐32→UTF‐8やUTF‐16とするIteratorまたはRange」

    • そこらへん、すなわち文字列の内部表現は、RubyのString#each_charなどの実例や文字列について (Gauche – A Scheme Implementation)といった議論など、それだけで30分で語り尽くせないお題になりますので、これくらいにしておきます。

「使ってね」なんて言いましたが、実際には、せいぜい「wchar_tを無条件にUTF‐16 or UTF‐32だと仮定しているコード」さえ消えてしまえばよい、という程度しか思っていません（Boost.RegexとかBoost.Serializationとかちょっとその辺怪しいんですよね……）。char/wchar_tでうまくやっているプログラムは、そのままで良いです。

スポンサード リンク

この記事のカテゴリ

  • ⇒ Boost.勉強会 #6 札幌の発表についてQ&A