堕天使の煉獄

ここ最近はダンジョンＲＰＧゲーム開発用のエディタ作りをやっていたのですが。
ちょっとエディタの作りの方も飽きてきたのでちょっと転進。
実際のゲームＰＧのほうのオレオレライブラリ作りの組み直しにとりかかる。

ずっとこっちに触れていない間、ずっと文字コード周りをどうするかというのを決めかねていたりで。
状況的にはあんまりかわってないんですよね。いまだにchar8_tが追加されないし。

コード自体の文字コードがutf8というのはもはやスタンダードなので良いとして、コード内の文字列リテラルをどうするのか。プロジェクト内での内部文字コードを何にするのか。

いまのところ、実行環境次第でも変化するものなので「明確な正解はない」というのが実情で。

とはいえ、明確な正解が出てくるまで待っているわけにもいかないので、なんとか将来的な変更も予想したりしながらやりくりするしかないぽ。

とりあえず今のところの方針は。
vc++環境でターゲットはwindowsという前提で。

■vc++文字コードセット設定は「unicode」を使用。
「マルチバイト」の方はshift-jis前提なのでもはや過去の遺物。古いプロジェクトの保守用でしょう。

■TCHATおよびwchar_tは使わない
wchar_tは環境によって中身が変わるため（現行win＝2byte、unix系=4byte）
文字コード周りはchar16_tやchar32_tなど環境依存でない物を使う。
が、後述の理由により、「表面的にwchar_tは使わない」で妥協

■文字列リテラルに_T("")マクロおよびL""は使わないでu8""で統一
TCHATと同じ理由で使わない方がよさげ。
専用のdxT("")などを用意して、環境に合わせて変える必要がある部分は対応。
L""はwin用専用コード内部でwinapiに直接渡す場合のみ利用。

■utf-8はあくまで受け皿
というのもutf8は文字列操作に向いてない形式。
向いてるのは外部から受け取ったりするときに文字化けし難い、受け取った文字はutf8だと判別しやすいという所。

■const char* std::stringの中身はutf8と想定
shift-jisはもはや過去の遺物なので使用しないのが望ましい。
中身がutf8だと明確にするにはchar8_tが必要なのだが現状ないのでしかたなくusing char8_t = charとかusing u8string = std::stringとか気持ち悪いけどやっておく方向で。

■utf8→内部コード→最終出力コードの流れで
コード内の文字リテラル、リソースファイル内の文字コードはutf8で統一。
画面出力の際に内部コードから最終出力コードに変換する。

■内部コードは……なんだかんだでutf16
文字列操作を考えると、utf16かutf32の二択か。
しかしwin上だと、char16_tとwchar_tはバイト列では同一になるとはいえ、reinterpret_cast使うのがなんとなく気持ち悪い……。
そしてstd::wcstolあたりの標準ライブラリにchar16_t対応版が無い。つかえないこともないけど毎度wchar_tにキャストの嵐に……。
その辺の事情はutf32も同じ。標準ライブラリの対応がまったく追いついてない。しかし文字列操作を全部自前で書くというのも現実的ではない。
てかwchar_tが4バイトになるunix系ではstd::wcstolとかどうなってるの？？
unix系ではそもそも日本語はじめ多バイト文字を使わない前提なかんじで無視？
内部コードはutf32がよさげなのだけども（一文字あたりつねに４バイトも使うのはアレだけど）strtol系が自前で書かなきゃ行けない。
to_stringもwchar_tの場合std::wostringstreamとかつかうんだけどもこのストリーム系もutf16、utf32はまだ未対応。なのでutf16、utf32は「早過ぎたんだ……腐ってやがる……」と巨神兵状態……。まだ使い物になりません。
じゃあどうするかと言えば内部コードはutf16としながらも内部コードを扱う文字クラスの中ではwchar_tで管理することに。結局内部コードをもつ文字列クラスはwin専用クラスに……。将来的にはこの文字列クラスの中身を書き換えるだけでいろいろと変更に対応出来る感じに組むしかないな……。

■サロゲートペア問題は局所的問題として解決
内部コードは現状、文字変換の標準ライブラリが使えるのでwchar_t(=utf16)がベターだとおもわれるのだけどもutf16にはサロゲートペアというお荷物仕様が。
問題になるのは文字列分割の際に、その境界にサロゲートペアの文字が来たときの場合なので、ゲームＰＧでは文字を１文字づつぺろぺろだすメッセージウィンドウとかぐらいでしょうか。ゲームスクリプトの解析なんかはスクリプト用のコマンドは半角限定にすればサロゲートペアの影響は受けないですし。
サロゲートペア対応はそれに特化したメッセージウィンドウクラスの中でのみ対処して、文字列クラスのなかではサロゲートペアがらみの処理は一切省くかんじで良いと思われる。（文字コードの相互変換部分では必要だけど）
サロゲートペアの表示自体はＤＸライブラリとかのお仕事なので気にしない。


そんなかんじですすめてみるかーと。

で、各種文字コード変換がひつようになるのだけども。
標準ライブラリの文字コード変換のstd::codecvtはどうも実装がかなりおそまつでセキュアでもないってことでc++17で非推奨……。代替用意してから消えて欲しいものですｗ
てことでutf8←→utf16はwinapiでもあるのだけどもそれ以外のutf16←→utf32とutf8←→utf32がwinapiでは用意されていない。
ということでその辺自前で実装することに。

そこでutf8←→utf16の変換、自前実装とwinapiとでコスト的にどのくらい差があったりするものなのか……と気になったので計測してみたり。

utf8→utf16変換　
結果の左は変換文字数を400文字　右は20文字
それぞれ10000回変換した結果。

MultiByteToWideChar(winapi)
debug = 280ms 210ms
relese = 50ms 14ms

自前変換utf8 → utf16
debug = 2370ms 300ms
relese = 54ms 12ms

ふむう。さすがwinapi。
独自最適化されてるせいか、デバッグビルドでもそこそこ速い。
一方自前実装の方はデバッグビルドだとクッソ遅いｗ
結果受け取りのバッファにstd::unique_ptr使ってるところで、リリースビルドだと生ポインタとほぼ同じコストになるけどデバッグビルドだとクッソ遅い。ってところで足を引っ張ってる物とおもわれる。
しかし何度か実行した平均値をとってきてるのだけども、少ない文字数の場合リリースビルドだと、微妙に自前実装のが速かったりする。文字数多い場合だとちょっと負けてるけど。
その辺、MultiByteToWideCharではやってる安全チェックのいくつかをすっ飛ばしてる部分の差が出てるのかなーとか。

そんな感じでutf8←→utf16変換に関しては、ｖｃ++上ではwinapiをつかって、win以外の方では自前実装のものを使う感じの運用にすることに。

あとは10000回変換してこの速度なら、毎度しょっちゅうコード全域にわたって文字コード変換してもたいしたコストじゃないんだなーやっぱり。とかおもたり。
ＱＴのソースコードと互換性ほしいので、文字列リテラルはu8""で統一したいのだけども、毎度変換コストかかるのはどうなのかなぁとおもてたので。
ＱＴに関してはＧＵＩアプリ作成用なので変換コストとか気にすることはないのだけども、ゲームＰＧではそうもいなかかったりするし。

しかし何となく適当に多めの文字列ってところで適当な文字列をその辺からコピペしたのがだいたい400文字ぐらいだったのだけども。
４００文字て普通の原稿用紙一枚分なんだよなと。
で10000回変換てことは原稿用紙10000ページ分てと、一般的な文庫本だと一冊４００字詰め原稿用紙換算だと５００ページぐらいらしいので小説本20冊分ぐらいか。
適当にぐぐってみたところ、一般的なビジュアルノベルの文章量てのは５０万文字ぐらいとからしい（しっかりとボリュームある感じの場合？　すくないのは２０万文字とかいうデータもあったのでよくわからん）50万/400で原稿用紙1250ページ分とかんがえるとその約１０倍の量のテキストを読み込んで（ファイル読み込みにかかる時間はこの際無視して）一括でutf8からutf16に変換してもリリースビルドなら50msしかかからないのかーと思うと、ゲームで使うテキストファイルも変換コスト避けるために内部コードと同じ文字コードに……なんてのもセコセコバッタの無駄な努力なのだなぁとかおもてしまったりｗ
無視出来るレベルのコストのために、無駄な面倒抱えるべきではないですね……。

そんな感じで、まだまだほんとにこれでいいのか？　と模索しながらの文字コード周り。
いっそもうｗｉｎ専用としてガッツり書いた方が楽なんだけどなーとか一瞬楽な方に流れそうになりながらガリガリと。