C++0xでの標準ライブラリを使った文字コード変換
basic_ifstreamのコンストラクタには、wchar_tを受け取るものがないのかな。代わりに、openメンバ関数を使えと。
2011-02-21 04:00:32@haroperi または、環境依存のファイルIOを使うかですね。ワイド文字使った時点で移植性が崩壊するのでWindowsにしか対応しないと開き直るとかどうでしょう。
2011-02-21 04:09:22@pepshiso 最終的には環境依存になっちゃうんですね。char *をwifstreamのコンストラクタに渡すことにしました。とりあえず上手くいってます。ありがとうございます。ちなみに環境はMacです。別の環境で運用する予定だから、また文字コードで嵌りそうで怖いですけど。
2011-02-21 04:22:04@rshhh ワイド文字はそのままですけど char16_t とか char32_t とか、utf-* の文字列リテラルとかが入ります。システムのエンコーディングがバラバラなのは変わらないので、銀の弾丸じゃないんですけど。
2011-02-21 04:26:34@rshhh うーん、codecvt まわりは詳しくないですが、あまり希望は持ってません。なぜかというと、従来は char のエンコーディングが1種類の実装依存のものであることが、標準のエンコーディング変換関数を使うなら必要なはずです。(続く)
2011-02-21 04:49:58@pepshiso standard code-conversion facet std::codecvt<Elem, char, std::mbstate_t> を満たす codecvtのオブジェクトをwstring_convertに渡してやれば (つづく)
2011-02-21 05:00:43@pepshiso wstring_convert::to_bytes() でワイド文字に対応したマルチバイトのバイト列のシーケンスに変換できるって書いてありますね
2011-02-21 05:01:41@pepshiso というか、これはアレだ、std::wstring と std::string (内部ではwchar_t と char )の変換をするための規格じゃないですか? C++0xで入る、char16_t と char との相互変換とはちょっと違う気がする
2011-02-21 05:03:55@pepshiso あーいや、忘れてください、22.5に Elem is the wide-character type, such as wchar_t, char16_t, or char32_t. ってのがありました。
2011-02-21 05:06:35@rshhh あー、そんな感じでしたね。問題はたぶん2つあって(1)文字列リテラルとかのエンコーディングが実装依存(2)charは実装依存のエンコーディングとUTF-8の2つのエンコーディングを持つと期待されることですね
2011-02-21 05:04:05