堕天使の煉獄

先日の続き～

とりあえず文字列クラスはこんでいいかーと見切りをつける。
あれから何か特筆すべき事といえば、やはりsprintf系のフォーマット書式はつかいものにならんなと。

str = glib::ustring::format(u8"%s : %d -- %s", u8"文字列", 20, u"utf16文字列");

こゆのがどうにも出来そうにない。
複数の文字コード入り交じった感じの。全部const wchar_t*固定てんなら簡単なんですが。

なんか頑張れば出来そうな方法ありそうではあるものの、えらく無駄が多い物になりそうで、とてもスマートでないものになりそう。
そもそも、ここ最近しばらくsprintf系なんて触ってなかったので、そうだっけ？　となったのだけども、適用後の文字列格納するバッファのサイズを取得する_vscwprintfの時点で、間違った内容(%dに文字列を対応させちゃったり)にしたら例外でぶち落ちるのね。即オチなのは関数にnoexcept指定してるからかもだけど。

数値にしても型に対応してないし、文字列もchar or wcharしか使えないし、事前チェックの方法もなく誤ったパラメータ与えるとぶち落ちるってんじゃこりゃ使い物にならんなと。
まあそもそも、デバッグ出力用には随分昔にこのフォーマット書式タイプの物を長らく使ってた事があったので、このタイプのフォーマット書式タイプも懐古的に残しておくかなぐらいの感じで試してみたのですけどね。
結果、やはり苦労してこの方式にこだわるよりも、とっとと過去の遺物として葬り去るのがいいという結論にｗ

と言うことでフォーマット書式系は、普通に型にも細かいエラー対応も出来るQStringのarg()をぱくったやつのみで行くことに。


文字関係ではもう一つ。
utf-8,16,32対応版std::regexってかんじのSRELL
ttp://www.akenotsuki.com/misc/srell/

なのだけども。
なんでかうごかなーい。テンプレート関係のエラーがずらずらと。
なんでやーと別プロジェクトでシンプルな構成のものにしたら動く～。

とおもったらなんでかutf-16だけうごかなーい。
普通にバグ？　ぽいですねこれ。

7568行目
typedef basic_regex<char16_t, u16regex_traits<char16_t> > u16regex;
↓
typedef basic_regex<char16_t> u16regex;

で動いたー！
char32_tの方にはテンプレートに二つ目のパラメータないのであるぇ？　とおもったんだよなぁ。
でもほんとはutf32の方にも本来は二つ目必要で、さらに其の先でバグってるという可能性もなきにしもあらず。
てか、SRELL。掲示板とかオープンな場所での情報がまるでないので、こゆときこまるぅ。
あとやっぱテンプレート周りのエラーは見てもさっぱりわからんｗ

あとこれは環境の問題っぽいんだけど
#if defined(__cplusplus) && __cplusplus >= 201103L
こういうマクロでc++11以降対応してるか判定してるんだけども（char16_t,char32_tはc++11以降）msvcではデフォルトだと/std:c++latestとかしてても__cplusplusの中身は199711 Lのままだったりする……。
/Zc:__cplusplusコンパイラオプションを自前で追加しないとだめな模様。
そこでまず嵌る。

次に、そんなやったら既定オプションとして、プロジェクトの共通設定として書き込んだろ。とおもって、表示→プロジェクトマネージャ……あるぇー？
現在開いてるプロジェクト名だけしか出てこない。
前はここからプロジェクトのデフォルト設定を設定出来たのだけども。
なぜか未だに形だけ残ってるだけでじゃあ出来る場所に移動させろよでおなじみのvc++ディレクトリ設定なんかもそこで出来たのですが。
なんか覚え違いしてる？　とググってみると……visualstudio2015以前までは出来たけどいまは出来なくなってるとの記述が……
今は共通設定はMicrosoft.Cpp.Win32.user.propsを直接編集エディタで開いて編集するしかないらしい。
……なんでそこまで共通設定を出来ないようにしたがるのだファッキン。
新規プロジェクト作る度に設定とかめんどくさすぎるだろうよ。
弊害が多いってんなら設定込みのテンプレ用意出来る用にするとかあるだろ……。
うち見たく、ｖｃ++使うのはＤＸライブラリつかったゲーム開発オンリーとか、限定された用途でしか使ってない場合だと、新規プロジェクト作った時点でＤＸライブラリへのパスとかは最初から設定されてて欲しいわけですよ。
他にも最近はもう使ってないけどboostとかSQLiteとかそのへんの外部ライブラリとかも。
これからは設定ファイルをエディタで開いて直接設定しなきゃ共通設定に設定出来ないとか、ほんとどうしてどんどん使いにくくしていくのかね。

んで、 /Zc:__cplusplusコンパイラオプション設定したあとビルドしたらまたSRELLでutf16使用するとエラー。
しばらく何処がおかしいのだと悩んだあげく、なんかエラー出力の感じがいつもと違うなと気づく。
今作ってるのは静的ライブラリとして作ってる部分で、エラーは本体の方のプロジェクトのmain.cppからエラーがでてるぽ。

……こっちのプロジェクトの方にも/Zc:__cplusplusコンパイラオプション設定しないとダメなのね。
ほらぁ、共通設定出来ないからこういう事に～ふぁーっく。


んで多倍長整数。

とりあえず、一桁を１０億進数の多倍長整数クラスを作ってみたり。
あんま別けすぎても繰り上がりの処理が増えるだけだしってことで、最大数の9億9999...同士を掛けてもint64_tで収まるのでこれでいってみようと。

とりあえず足し算、引き算あたりは簡単に実装できる。

かけ算がややこしいなこれ。
事前に調べたKaratsuba法ってのは、それぞれ二分割したとき限定の方法だったのねこれ。
欲しかったのはn分割 * m分割 で速く計算できる方法だったのだけども。
そっちはToom-Cook法で、Karatsuba法はToom-2にあたるのだとか。

で、Toom-Cook法ての調べると、もう何が何やら。数式ばっかでゲボが出そうですよ。むりぽー。数学キライ－。

で、今のところこの多倍長整数が必要なのは、放置ゲーム的な物を一回作ってみようかなと思ってからの所なので、実際にゲームデザインとして、n桁 * m桁のかけ算てでてくるのかなぁと。ちな桁の一つは前述の１０億進数での桁数です。

普通に考えて、n桁 * 1桁以外出てこないんじゃと。
可能性としてはn桁 * 1桁+小数部もあるか。倍率が小数点とかこの手のゲームではよく見るし。
そうなると、n桁 * 二桁だけあればよいのではと。
二桁限定なら普通の一桁ずつ掛けて足していく、普通の計算方法（筆算のときのあれ）で十分なんじゃないかと。コスト的にもn桁 * m桁のようにふくれあがることもなさそうだし。

小数部の計算結果用に、桁の右シフト（ついでに左シフトも）を用意しておけばあとはシンプルだなと。
そんな感じでかけ算も泥臭くはあるものの実装完了。

……割り算はさらに厄介そうなのと、そも使わないor小数部のかけ算（割る2なら0.5掛ける）とかである程度は代用できるし……ということで割り算は見なかったことにすることに。

んであとは多倍長整数の文字出力部分を。
一時は、もうめんどくさいからboostいれちゃうかなとおもったけど思いとどまった理由の一つに、boostの多倍長整数ライブラリは、文字出力が一括全桁しかないっぽいってのがあって。
結構この数値の文字化って重たい処理なんですよね。
で、毎度全桁出力とか無駄が多すぎるだろと。

実際的に使うのは、頭から5～6桁しか使わないわけですよ。
68.458quintillionとか1.58954 E+58とかこんな感じで。
なので必要な最小の桁だけ文字化する感じのがいいなーってところで、やっぱ自前で組むかーって流れだったりする。

しかし英語表記になると、結構諸説あってどれがポピュラーなのか判らないですね。途中で並びが違うのあったりとか、こっちにはなくてあっちにはあるなんてのもあったりして。
どれが正しいのかさっぱり判らん。
あとgoogolplexplexplexとかみただけで桁が想像も付かん……ってのもあるんですけど。

この手の放置系ゲームいくつもやってるとundecillionとかこのあたりぐらいまではなじみがあったりするので、だいたいどのくらいーてのがぼんやりと浮かんだりするんですけど。
とはいえScientific　科学的表記？　ていうのの 1.123456+10
と、最上位一桁で其の桁までの桁数を後ろに+でつけるのは、数の大小はすぐに判別付くけど、ちょっと味気ないんだよなーというところもあって。

んでも日本表記だと桁が少なすぎる。無量大数にあっちゅーまに到達してしまう。あと単位の一つ、「杼（じょ）」これは正確でなく代用文字の方なんですけど、正式な方は外字で、表示できるか環境次第という問題なんかもあったりする。

細かいところでは日本式だと４桁区切りで単位が変わるのだけども、英数だと３桁区切りだったりする。
その辺で、多倍長整数の桁も９桁てのは３で割れるので英数だと扱いやすかったりする。

そんな感じで多倍長整数クラス出来。
数式怖い。