なぜか文字コードの設定がマルチバイト文字になっていて面倒なことになっていた。 const char*がsjisになっていたっぽい。
2012-08-18 18:17:58MSVCはビルド設定をUNICODEにしてもconst char*のリテラル文字列はsjisにしてくる。 ひどい、これはひどい。
2012-08-18 18:26:03つまるところstd::stringはstd::basic_string<sjis_char_t>だったと。 charの文字コードがどうなるかはある程度環境依存だった気がするけど。
2012-08-18 18:31:53@Sigureya 文字列リテラルの符号化方法は実装依存だし、UNICODEはプリプロセッサマクロでしかない。Unicode文字列リテラルが欲しければワイド文字列を使わないといけないし、CP932に無い文字を書きたいならソースファイル自体をUTF-16で書かないといけない
2012-08-18 18:32:27その動作自体は規格準拠なのでそれでVC++責めても仕方ない。 RT @Sigureya: 以前MSVCがUnicode対応残念とは聞いたけど、ここまでひどいとは予想していなかった。
2012-08-18 18:35:15@Sigureya C++11にはUTF-8文字列リテラルがあります。u8"..."ただし、charの配列なので通常の文字列リテラルと型で区別はできません。
2012-08-18 18:37:07@kikairoya この世界のMSVCです。MSVC11でもC++11のUSCリテラルには対応していないと聞いています。他の二大主要C++コンパイラーは対応しているのに。
2012-08-18 18:39:07@bolero_MURAKAMI 私もその件で掛け合ったのですが、基本的に、charとは、文字というよりも、バイト単位のバイナリデータをいれるものであるという認識があるらしいのです。
2012-08-18 18:40:01@EzoeRyou 他の二大主要コンパイラーはCP932で書かれたソースファイル中の文字列リテラルを自動的にUnicodeに変換する機能はありません
2012-08-18 18:40:29char8_tとか別に無くても、それが本当に必要なら「エンコーディング情報を持った文字・文字列型」を定義すべきだし、char16_tとかも実際要らん
2012-08-18 18:41:42@kikairoya ソースファイルの文字コードは規定されていません。現時点で、UCSのエンコードではない文字コードは、互換性のためだけに使うべきで、今から書くソースコードをCP932にするというのは、そもそも間違っています。
2012-08-18 18:43:09