char16_t/char32_tですよねそんな型があったのか。(UTF-16のサロゲートを除けば)1文字16bit/32bitで固定だと思うけど、UTF-8は1文字のバイト数が変動するからね。内部処理はUTF-16/32でやって、I/OのときだけUTF-8に変換するのが楽だから、データ型として提供する必要性は薄いと判断されたのかなー、とか思う。アキラu8プレフィックスはありますけど。char型の定義が修正され、少なくともUTF-8の8ビットエンコーディングを格納出来て、コンパイラの基本実行文字セットのあらゆる文字を格納するのに十分な大きさを持つ、とされた。以前は後者だけを満たしていれば良いとされていた。文字列が渡された場合に正しく動作することが保証されるように、ライブラリが見直される、ということになるか。保証されるように、ライブラリが見直されるどぉでしょね。rigarash話題だけ振って、その後発言がなくて申し訳ないです。僕自身はgcc/glibcな世界しか扱っていないので、問題ないのですが(というかascii以外の文字をプログラミングで使わなくてすむ環境にいる)、BSDな人のコメントでいえば、http://www.hi-matic.org/diary/?20081118#18あたりがまとまっているかと思います。コンパイラとlocaleの関係は悩ましいですね。相互変換も必須ですよね。ひろゆきんーと、問題になっている点がちょっと不明瞭なんですが・・・。2つ疑問点があります。1つめは今の議論って要はコードポイントを1文字として認識するにはどうするかってお話なんでしょうか?(^^;そもそもUnicodeは文字合成の仕組みを持っているのでコードポイント1つでは文字を表現しきれません。ここでいう文字合成というのはサロゲートペアを除きます。そのため、Unicodeで1文字を十分に表現できる型となるとUTF-8でなくても1文字単位で可変長となる型が必要になってしまいますね(^^;Unicodeは結構複雑なので、1文字という単位をどのようにとらえるかによって、単純な固定バイトの型にすることは難しいと思います。サロゲートペアだけでも1文字が4byteになってしまいますし、ディアクリティカルマークなどを利用したものになると4byte6byteとどんどん増えてしまいます。επιστημηもともと「ASCII通れば無問題」がベースになってっとこに無理くりmulti-byte文字をねぢ込んでるのが諸悪の根源。導入したがこいつのサイズは処理系の勝手。4通り、std::basic_stringを考えると8通り。「それらの相互変換とか要るよねー」なんて言い出すと混乱を極めるわけです。u/U/u8プレフィックス入りますよ。http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1333.pdf標準ライブラリの影響とかは調べてないですけど。soda二種類の話が混ざってますね。