堕天使の煉獄

「ComicSoon」
漫画発売日リスト取得と登録作家名、作品名で一括検索ツール。
http://www.rengoku.sakura.ne.jp/program/software/comicsoon/index.html
ver 2.1.0　公開。

ローカルにある過去データから一括検索する機能追加～



あんまし一括で過去データぶっこぬきしちゃうと、情報サイトのほうでなんか対策とかされそうなのでどうなのかなーとペンディングにしていた機能なんですが。
やっぱ某氏の言うようにように欲しい機能ではあるので、とりあえず試しに追加してみたり。

デバッグビルド中はくっそ重くてどうなんだコレと思ってたのですが、リリースビルドにすると、３年分のデータを数１０件の作家名で検索かけても、数秒で終わる……。メチャ軽い。

そんでちょこちょこ試してたらばある事に気づく。

週間連載の作家さんの結果と、月刊連載もしくは不定期連載な作家さんの検索結果が如実に差が出るのまで見えて来ちゃうんだなとかｗ

情報サイトにもともと三年分しかないので過去三年分しか取れないにしても、月刊ペースの作家さんだと、せいぜい3～4冊ぐらい。
週刊だと普通に１０冊ぐらい出てくるんですよね。やっぱ週刊ペースってすげぇ生産ペースだよなと。週間連載が出来る漫画家さんは超人なのだ（コミックマスターＪより）

ついでにもう一ネタ


ちょっとまえにも触れたネタだけど。
鶴田謙二氏の冒険エレキテ島２巻、なんか毎月のようにリストに載ってるなーというので、過去データからの検索にかけてみるとこんな感じになってたのねと。
最初は2016年11月22日でそのあとは2017年03月23日からずっと毎月発売日リストにｗ
ここ最近は担当者が意地になってるのか、プレッシャーかける為に毎月載せてるんじゃないかと邪推ｗ


ＰＧネタとしては、以前から上手く行かない処理があって。
今回のでもつかっているのだけども、長い時間がかかる処理の場合、別スレッドで実行するみたいな処理で、処理中に中断のやり方がよくわからない。
中断するだけならできるんだけど、そのあとスレッドの終了処理タイミングと、実行もとのオブジェクトのデストラクタのタイミングとかでぶち落ちるんですよね。
「中断しますか？」みたいなダイアログだすと、なんでか中断指示だしたスレッドが動き続けて、ダイアログ閉じる前にスレッドの中でやってた処理が終わって処理終了時に実行もとのオブジェクトにシグナルで閉じる指示とか出してるもんだから、これもなんかダイアログ閉じた瞬間に落ちる～。

どうもダイアログもまた別のスレッドで処理してるので、その辺でなんかおかしな事になってるっぽい。
とりあえず中止かの質問ダイアログ出すの止めて進捗のプログレスバーだしてるダイアログのＸボタンおしたら、ぶつっと確認無しで終了にしてアレコレやったりしたら、とりあえず落ちないで処理の終了は出来る様になったんですが。
いまいちスマートでない感じに。

この辺あんま情報ない＆あっても英語の情報ばかりでこまるぅ。

あとはなんか最近のｖｅｒのＱｔのデバッグビルドはなんかおかしい。
異様に遅くなったのもあるけど、今回のツールの場合、Ｗｅｂからファイルをダウンロードするとき、開始するまでにえらく待ち時間があるのと、ＤＬ中の現在読み込んだサイズと、全体のサイズてのがシグナルでおくられてくるのだけども、デバッグビルドだとなぜかずっと全体のサイズがつねに-1。
なんかデバッグビルドだとまともに動いてるのかのチェックすらままならなくなってきてるぅ。これほんとどうにかならんのか……。


も一つのほうのゲームＰＧのほうでは。
とりあえず試しに文字コードutf-8統一路線で進めてみようとおもったのだけども。
utf-8の文字列に対して文字数でsubstr出来るのとかちまちま作り出したところで、やっぱutf-8は文字列操作には向いてないんだなぁと。

ただ、現時点で、wchar_tは使わない、文字コードが環境依存で変わるっていう状況はやはりうざったい。てことで環境に依存しない文字コード固定で…･･っていう方向は間違ってはないとおもうのだけども。どうするのがスマートなのか。

そこでソースコード内のリテラルは全部u8""のutf-8で書く事にして。
で、独自のstring型を用意して、内部ではutf-16(std::wstring)で管理する感じにしてみることに。
独自のstring型はconst char*でもそのまま受け取れる（const char*はutf-8限定）
と、結局QStringのパクリみたいな感じの方向でいくことにｗ

しかしまあ、const char*で受け取るのも、暗黙でutf-8想定というところが気持ち悪いといえば気持ち悪い。char8_tがないからなぁ。
とはいえ、もしchar8_tあったとしたら何バイトになるのだろうか。

char = u8'a';

てのがわりと最近vc++でも有効になったのだけども。
これって１バイト文字の範囲のutf-8に限るんですよね。

char = u8'あ';

なんてのは当然無効。

んで、ちょうどutf-8対応のsubstr作ってたときに、コードの仕様とかまたみてたのだけど、どうも今まで結構古い仕様を参考にしていたようで、2003年11月からの新しい（つーても2003て随分前じゃん……）仕様だと、どうもutf-8の一文字の最大バイト数は４バイトになるらしい（ニコイチな文字とか特殊なのはべつとして）
以前はasciiコード互換の１バイト文字以外は3～6バイトっていう認識だったのですが。ただこの情報もほんとに最近のなのかよくわからんｗ
んでもutf-32とutf-8の関係って、utf-32をシリアライズしたものがutf-8という表現で解説してる所もあったりで。utf-32は４バイトじゃないですか。そうなると両者の差があんまり……。
英語圏の１バイト文字しか使わない人達にはutf-8ウマーなんだろうけどさ。

まあ、結局の所、欲しいのはchar8_tではなく、u8""の文字列をconst char*出受け取ると、中身がutf-8なのかどうなのか判らないというところで、これはutf-8デスよと規定するutf-8を扱う型が欲しいと言うだけなのですよね。
現状、utf-16とwchar_tがそんな感じの状況ですよね。
そのままではchar16_tはwchar_tに代入できないですし（内部のバイト列は同じでも別の型なので）。
それのutf-8版が欲しいだけなんですけどね……。

んでもutf-8のまいど文字の先頭位置（バイト単位）で取得するためには毎度先頭から走査するってのは実際組んでみるとうっとうしい仕様だなと。
文字単位で移動するイテレータとかそんなんも作ってみたりとか、一括で文字数とバイト数の対応のリストを作ってからアレコレするみたいな方向とかいろいろ試してみたけど……
普通にutf-16とかに変換しちゃったほうが楽だねコレ。という結論に達したｗ

utf-8だとstd::regexもダメ臭いし（実際には単なるバイナリ比較になってしまうので、途中の多バイト文字の中のasciiコードにマッチしてしまう）
std::regexで分割する（htmlタグ風のパーサーとか使う時とか）時はサロゲートペアチェックしてのutf-16かutf-32に変換してから……って感じになるのでしょうか。
以前組んだ奴はさろげーとぺあってなんですか？　って感じで目線をそらす感じでutf-16のままつかってましたが、特に誤マッチとかもなく普通に使えてたりして。
デバッグビルドの時だけサロゲートペアチェックしてそこで問題無ければリリースビルドではサロゲートペアの処理しないutf-16固定というのも有りなのかなーと言う気も。

ほんと文字コード回りってめんどくさい。