堕天使の煉獄

ここ数日、急に秋っぽい涼しい日が続いてますが、一時的な物でまたしばらくしたら残暑キターな感じになるんでしょうかね。

そんななか。
そろそろほんとゲーム作ろうよってかんじで久々にｖｃ++立ち上げたのですが。
VisualStudio2017 update3来てたのですね。ｃ++17対応がちょっと増えてる。

コンパイラの実装状況
ttps://cpprefjp.github.io/implementation-status.html

「if文とswitch文の条件式と初期化を分離」
これは早くほしいなーとおもってた物の一つですね。

if(int index=getIndex(); index == 0){
//...
}
で、スコープの外ではindexはもう消えてるっていう。
おなじことをやろうと思うと以前は

{
int index=getIndex();
if( index == 0){
//...
}
}

と無駄にスコープで無駄に囲わなきゃいけなかったので。
このためだけにインデント深くなるのはうっとうしい。
あと自分ルールで大体決まってる返値の受け取り変数に同名が使いやすくなるというのも。
if(auto result=getHoge(); result != nullptr){
//...
}
if(auto result=getHoge2(); result != nullptr){
//...
}

なんて続けて書いてもお互いのresultは別ものでそれぞれのスコープの終わりで消滅するので衝突も起らないのです。

「if constexpr」
最初この文字を見たときには、キタコレとおもったのですが、中身みてしょんぼりの奴ｗ
欲しかったのはコンパイル時なのか実行時なのかで処理を切り替えるようなものだったのですが、if constexprはテンプレートの実体化を抑制する機能、ということらしい。
なので今のところ使うあてはなさそう。
コンパイル時なのか実行時なのかで処理を切り替える機能欲しいな－。
たとえばべき上を求める場合、コンパイル時はconstexpr関数で適当に書いたので実行して（どうせコンパイル時間中に計算されるので実装は適当でも答えあってれば実行時にはなんの影響もない）実行時にはstd::pow使う。みたいなのができたらなと。一つの関数で実行時とコンパイル時で切り替えられるのが欲しいぽ。
現行ではそれらは別けて別関数とかにしないと無理ぽなので。

「構造化束縛」
タプルが使いやすくなるですね。正直std::get<n>(taple)て書き方は助長過ぎてダサ過ぎ感はんぱないので。

「ラムダ式をconstexprとして使用できるようにする」
ちょこっと一回だけとか使う物をconstexpr関数を定義しなくてもラムダ式で書いちゃえるのは楽でよいですね。

残念なのはまだ未対応の
「畳み込み式」
単に可変長引数の中身を連結するだけのときでもまだ再帰で書かなきゃ行けないのかー。めんどくさー。

もっとがっかりなのは、Ｑｔで今回ふえたのつかえねーじゃんってこと。
「if文とswitch文の条件式と初期化を分離」試してみたら普通にエラー。
てかやっぱQt5.9からなぜかmsvc2017の32bitビルド版が提供されなくなってるんですよね。ＱＴのブログでもつっこまれてたけど、これ以上数増やしたくないだの時代はもう６４bitだよ何か問題でも？　とかなめた解答返ってきてたりするし。msvc2017は2015とコンパチだからmsvc2015版でもｃ++17対応増えたのは適用されてたりするのかなと期待したのですがやっぱ無理ぽらしい。
c++17対応おくれてんじゃねーか。影響でまくりだよ……
なにげに未だにshared_ptrでmake_shared使うと引数無しの場合赤線でるし。
clang解析ＯＮにしたらいいんだろうけど、以前のｖｅｒでソースコードロックして上書き保存不可＆大量のゴミバックアップファイルを大量生産するバグなのか環境依存なのかの現象があって以来clang解析offがデフォだし。
むー。
なんかいろいろ不満たらたら。


だのになぜかまたＱｔプログラミング。



ｖｃ++のプロジェクトもソースコードはutf8に統一しようかなとおもたのですが、文字コード一括変換するツールいくつか物色してみたところ、どれも変換自体はうまくいくのですが、

・フォルダドロップでサブフォルダまで登録
・フィルタで指定した拡張子のファイルのみを読み込む
・文字コード自動判別で成功してるのか変換前に確認
・変換後バックアップからの復元

このあたりが全部そろってるのが見つからない。こっちはあるけどあっちがないみたいな感じでなかなか良い物がないぽ。
特に三つ目が無いんですよね。
自動判別に自信があるのかしらないけど、もともと100％解析出来る類のものではないですし。一旦ほんとにあってるのか確認ぐらいはしたいですよね。
バックアップの方法もいくつか選択出来るといいですよね。

で、結局自分でつくることに。

今のところ、バックアップ回りは拡張子変えたバックアップファイルを同じ場所につくる（復元機能で一括復元可）元ファイルをゴミ箱に送る（ゴミ箱から元の場所にで復元可能）バックアップ取らずに上書き（変換うまくいくの確認済みの場合）
の三つを用意。
バックアップファイルの一括削除もあるといいかな。
サブフォルダまで登録できるとバックアップファイルを消すのは結構大変なので。

変換前に自動判別結果の文字コードでテキストを実際に読み込んでプレビュー機能あたりがやっぱ結構ほしい機能なんじゃないかなと。
で、うまく判定できてなかったら手動で個別に読み込みコードを指定し直して～とできるのはやはり便利。
……自動判定あたり結構適当に組んだので、余所様のところの自動判定の精度に自信ありって所にはまるで対抗出来る自信ないので、そのへんのフォローも兼ねてる……ｗ
実際上のプリスク画像のでも、bom無しutf-16の判定失敗してますしね。
まあ中身の文章量とか内容（使われている文字コード種類）でも判定精度に影響あるのでアレですが。
ちないま上の貼り付け画像みてて気づいたけど「utf-16le - コピー .txt」がutf-8判定になってるのは、変換テストでutf-8に変換後のファイルだからですとフォロー。


なにげにちょっと前に作ったソースコード閲覧用のツールの文字コード判別ルーチン使い回してるのですが、世にある文字コード変換ツールも大抵、開発者の人、他にエディタも作ってたりして。その文字コード判定部を使い回してるパターンおおいんだなとおもって、同じ流れで作ってるのに気づいて然もありなん……となんだか納得しちゃったり。

ちょいと嵌ったのが、ＱＴは改行コードの\r\nと\nの判別は自動でやってくれて、書き出しもテキストモードで書き出すと、環境に合わせた改行コードでかってに出力してくれる便利機能付なんですが……。
今回のように改行コードを自分で指定したいってときにどうやるのかちょっと迷った。
結論は単に自前で改行コード付け足しつつ、テキストモードじゃなくてバイナリで書くだけという、ちょっと考えりゃ判るじゃんというオチでしたがｗ

なんでも自動化されてると普通に使う分には便利でいいんですが、ちょっとつっこんだことをやろうとおもうと、かえって面倒だったり。


で、ｖｃ++でゲームプログラミングーのつもりがまずソースコードの文字コード全部変換しよう→変換ツールなんだかんだで結局自作といきなり脱線ぽｗ

しかし、ここしばらくｖｃ++触ってなかったけど……。
文字コード回りはやっぱまだまだコレって言う決定的な判断基準がないなと。


ｖｃ++とＤＸライブラリでゲーム開発という前提で。

まず考慮すべきは、最終的な出力にはｗｉｎの内部文字コードのutf-16が使われるということ。

んでｖｃ++は、ソースファイルの文字コードがなんであろうと""で囲われた文字リテラルの文字コードはshift-jis（正確には違うけどまあ同じ）になる。
で近年、c++11の機能で、

u"" = utf-16
U"" = utf-32
u8"" = utf-8

と、プレフィックスを付けることで文字リテラルの文字コードをプログラマが明示的に指定出来る様になった。

んでもって厄介なのはvc++の文字コードセット設定の
「マルチバイト文字」
「Unicode」
という設定。
混乱の元ですね。

これらの両設定で同じソースコードを扱えるようにするためにTCHARという文字用の型があり、「マルチバイト文字」ではchar、「Unicode」ではwchar_tになる。
で、wchar_tはプラットフォーム依存で中身がかわる。ｗｉｎなら2バイト、unixだと４バイトとかいった風に。
文字リテラルは_T("")というマクロで中身が文字コード設定によってconst char*とconst wchar_t*に振り分けられます。

んでもってutf-8は１バイト単位で扱うcharなので「Unicode」を選択してしまうとTCHARは使えなくなります。２バイト単位とか意味無いですし。
となるとutf-8はunicodeだけど、「マルチバイト文字」を選択するべき？
なんていう混乱も引き起こしたりと、TCHAR回り、vc++の文字コード設定回りは、はっきり言ってぐだぐだです。時代遅れまったなし。

んで、どうするのがベターなのかしばらく考えて見たところ、自分なりの結論は……。

「TCAHRとか_T("")マクロあたりを窓から投げ捨てること」

ですｗ

そもそもこの辺はwindows上で書くｗｉｎ依存のコードで、TCHARだとか_T("")とか使ったソースコードを余所の環境にもっていったとき（たとえばQTとか）全部書き直さなければならなくなる。
winで組む場合、最終的な出力でutf-16に変換すれば、後は内部文字文字コードは何でも良いわけです。

そうなると、ソースコードはutf-8で統一。文字リテラルもu8""でutf-8で統一。
ＤＸライブラリの場合なら

std::string str = u8"あいうえお";

DrawString( 0, 0, toUtf16(str), -1);

な感じで、出力の際にutf-16に変換して使うのが一番いいんじゃないかなーと。
ｖｃ++の文字コードセットは「Unicode」で。

ＤＸライブラリにも文字コードの変換機能はあるのですが、なぜか文字コードセットが「Unicode」だと使えないので、(wchar_t＝2バイト単位で文字を受け取ってしまうので、そこから１バイトずつ拾って変換てのがネックなんだろうな……)自前で変換、もとい上の例では変換したのをDrawStringに送ってますが、実際にはDrawStringのラッパを作ってutf-8文字列を直接受け取って内部で変換して表示すると言う形になるでしょうか。

……char8_tがなく、charで受け取るしかないので、utf-8の文字列を限定で受け取る……というのが出来ず、ローカルルールで文字列はすべてutf-8限定とする。というようなかんじにせざるを得ず、スマートに書けないのがアレですが。
utf-8の泣き所は[]での添え字アクセスでの文字数単位での出来ない所なのですが（substrとかも）その辺の機能追加したu8stringとか自分で作るのがいいのかな?

最終的にはutf-16になるので文字コードセット「マルチバイト文字」はもはや化石設定。使うべきではないし、つかたっところで将来的にもなんのメリットもないぽ。

そんな感じで運用すれば、ＤＸライブラリの機能とかの環境依存機能部分をのぞいた所は、Ｑｔとか他の環境のソースコードの互換もある程度は取れるかなと。

んで結局、まずはwin依存コードを排除すなわち

「TCAHRとか_T("")マクロあたりを窓から投げ捨てること」

という結論に。

内部コードにutf-8はほんとにこれがベストなのかはまだまだ不透明ですけど……。

少なくとも、utf-16はstd::regexから見捨てられたようですし（サロゲートペアあたりの処理とかの問題ぽ）現行windowsの内部コードがutf-16であるということ以外では使いどころの薄い文字コードとなりつつあるぽ。
utf-32にしても、固定長バイトの文字コード幻想は打ち破られて、結局いまの所ではutf-8がベターというところでしょうか。
utf-8でもbom付bom無しとかの問題もありますしね。

ほんと文字コード回りは混迷をきわめるぅ。

ｃ++の標準機能での文字コード変換機能だったcodecvtはc++17ではdeprecated
になったそうですし。理由はセキュアな問題だそうです。代替用意してから消えてよと……＿｜￣｜○

winならwin32apiで環境依存だけどMultiByteToWideCharを使うし、QtならQtの機能で文字変換ついてるのでまあ、困りはしないんだけど……
でももともとcodecvtてパフォーマンス的にも微妙とかなんかでみた記憶もあるしな。

ちなみにQtのQStringは内部コードはutf-16なんですよね。
でも基本的には

utf-8→QString→環境にあわせた文字コード

と言った感じでその中継ぎをQStringがやってくれるので、実際の所QStringの内部文字コードが何であるかは意識しなくてもよい感じになってるのです。
内部がutf-16なのはやはり文字単位でのアクセスがやりやすいから何でしょうね。
そもＱＴはGUIアプリとか向けなので、事情がちがう部分もあるのですよね。
GUIアプリなら、文字列を右から左に送るたびに文字コード変換してもべつにいいけどゲームＰＧでは１フレーム内に必要な処理を行なわなければならないと、速度的な制限があるため、文字コード変換というコストもなるべく抑えたいというところもあって。
そうなると、最初からutf-16で統一、u""で統一。というのも案としては出てくるのですが、一文字ずつ出力とかするさいにサロゲートペアの処理はどーするの？　とか、素直に使えなかったりする部分もあるので（とはいえ普通の日本語しか使ってなければサロゲートペア無視しても問題にひっかかる確率低いですけどね）
あとwchar_tとutf-16はwin環境においては、同じ文字の中身のバイト列は同一だけども、型が違うのでそのまま代入出来ませんしね。
reinterpret_castとか使うのおっかねぇ。gotoよりおっかねぇ（私だけ？）

そんな感じでとりあえずutf-8統一案が今のところは現実的ぽ？