エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント2件
- 注目コメント
- 新着コメント
![mattn mattn](https://cdn.profile-image.st-hatena.com/users/mattn/profile.png)
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
C++0xのUTF-8対応に問題あり
今まであまり気にしていなかったのだが、C++0xのUTF-8対応には、非常に深刻な問題があるように思われる... 今まであまり気にしていなかったのだが、C++0xのUTF-8対応には、非常に深刻な問題があるように思われる。 C++0xでは、u8 encoding prefixを使うことによって、UTF-8でエンコードされた文字列リテラルが使える。 u8"あいうえお" ; しかし、このリテラルの型は、char const [16]なのだ。(UTF-8では、ひらがなは一文字3バイトを要する。null終端を付け加えて、サイズは16となる。) しかし、charという型は、歴史的に、あらゆるマルチバイト文字コードを格納するのに使われている。charを入力に受け取った時点で、それがどんなエンコードを使っているかは分からないのだ。 つまり、以下の様な関数を書いた場合、 // UTF-8の文字列を入力に取る関数 void f( char const * ptr ) { // ptrがUTF-8文字列を参照している保証
2011/04/20 リンク