C++文字コードのお話

若年寄(もう若くない) @kikairoya

@EzoeRyou だから要らないと言っています

江添亮 @EzoeRyou

@kikairoya std::uint16_tとかの方がいいんですか？

若年寄(もう若くない) @kikairoya

@EzoeRyou "「エンコーディング情報を持った文字・文字列型」を定義すべき"

狂える中３女子ボレロ村上／陶芸C++er @bolero_MURAKAMI

文字列型(クラス)はともかくとして、プリミティブ型が文字セットの情報を持っていて嬉しいケースはさほど思い当たらない。

若年寄(もう若くない) @kikairoya

まず組み込み型を直接扱うこと自体がナンセンス

江添亮 @EzoeRyou

@kikairoya char16_tやchar32_tはエンコーディング情報をもった文字型ですが。

若年寄(もう若くない) @kikairoya

@EzoeRyou Unicodeをあらわす型だけがあって何の役に

狂える中３女子ボレロ村上／陶芸C++er @bolero_MURAKAMI

std::char_<std::cp932>::type

くりんぺっと @climpet

文字コード関連の処理は、C++では不向きだと思う…

Akso de la Malbono @Cryolite

char を受け取るすべての API の char8_t オーバーロードが現れる！！！！！

Maxしぐれん @Sigureya

自前の文字列型を用意しろの意味がやっと分かった。

箱プリン @boxpurin

C++で文字コード関係は発狂の恐れもあるので

江添亮 @EzoeRyou

@kikairoya C++的には、UCSをUTF-16やUTF-32でエンコードした型以上の、賢い型はライブラリ側の仕事です。コア言語のリテラル式がライブラリの型を返すというのは、余程の事情がないと認められないでしょう。typeidとか初期化リストのように。

若年寄(もう若くない) @kikairoya

@EzoeRyou "char16_tとかも実際要らん" "組み込み型を直接扱うこと自体がナンセンス"

じょい @joy1192

文字コードTLになっとる…。ファイルからリアルタイムでゲーム内容読み込む時に色々と困って、結局SJIS決め打ちという哀しみを背負った身としては、誰かが頑張って作ったライブラリか、各種文字コードの表現の分かりやすい解説が欲しいのう。

じょい @joy1192

Boostは開発者の殆どが英語圏だろうから期待してもアレだろうし…。自分で作るつーても、文字コード関連書籍とにらめっこして結局決め打ちするわけで、あんまし楽しくなさそう。

じょい @joy1192

SJIS決め打ちだと1文字目の値見て漢字か半角か云々か判断して云々という、クッソ汚い実装しかできなくて非常にアレ。リファクタリングしようにも、コア部分が本当に……ああっ…

Akso de la Malbono @Cryolite

char16_t, char32_t にはエンコード情報はまったく乗ってなくて，あくまでライブラリや API の convention としてエンコードの保証がそれとな～くあるだけでは～．

Maxしぐれん @Sigureya

ここ数十分のTLで覚えたこと。 charの文字コードは実装依存。 u"文字列";とかやっても型はchar; TCHAR周辺はWindowsのAPIにしか関係しない。

若年寄(もう若くない) @kikairoya

ところでchar16_tの配列がUTF-16文字列を表現するという規定はどこに

Fadis @fadis_

https://t.co/pp1QKFXz エンコード情報ののった文字列型を作れば良い

若年寄(もう若くない) @kikairoya

u'x' は x のコードポイントが0xFFFFより大きいと ill-formed で使い物にならん

江添亮 @EzoeRyou

@kikairoya そういう保証はありません。

相沢陽菜 @fetus_hina

@kikairoya え・・・そんな仕様だったの…

若年寄(もう若くない) @kikairoya

はーUTF-8があればどうにかなるとかいう世界しか知らない人は幸せですね、とか(放送業界のあたりを眺めながら