堕天使の煉獄

firefoxの更新きてたので更新かけたらば……。
まーたタブが一番上に移動してやがる……。

いい加減、勝手にレイアウト変更するような更新止めて欲しいわ……。
んでググってみると案の定、firefox65でタブを下にしたいんですけど的な記事がぽこぽこ。
いい加減、タブを下にしたい層が一定数要るって事を認識して、設定一つで位置変更出来る様にしてほしいわ。なんで執拗にタブを上にしたがるのか……。
てか今回の場合は、メニューバー周りのレイアウトを新しいＣＳＳの機能に置き換えたみたいで、firefox58ぐらいだったか？　からuserChrome.cssでタブを下に移動させてたのだけども、その辺書き直さないと行けない感じらしい。

てか更新の度にこんなんやらされるのめんどくさすぎだろ……。
なんかfirefoxって、バージョン番号急にあげ始めたあたりからおかしくなったよな。破壊的な変更最近多いし。
とはいえいくつかのアドオンが便利すぎて代替はなかったりするので……。

てか新しくなったcssのレイアウト方式っつっても、普通にそんな日本語の解説ページなんかないし、まずどう変わったのかとかから調べるのだけでうんざりですわ。
とりあえずいろいろやってるウチになんとかタブは下に下げれたんだけど、こんどは移動した分空白がのこってその空白が消えないｗ

個人的には

ツールバー（戻るボタンとか検索とかアドオンアイコンとか）
タブ

の二段のみでサイト表示部分は大きく取りたい派なのですよね。
メニューバーは最近のｖｅｒでは「三」ボタンから大抵のことは出来る様になったので必要無いし。
なのにタブは下に行った物の

空白（もとのタブの幅サイズ分の）
ツールバー
タブ

の三段構成にｗ
こんなんいやや。
メニュー表示にチェック入れるとちゃんと空白部分にメニュー表示されるし。
この空白消したいんや。どうすればいいんやー。
ここがcssではなんて要素なのかもわからんし。ググっても英語ばっかりだしぃ。
ってのでしばらく悩む。

結論
#navigator-toolbox {margin-top: -24px !important}

無理矢理力業すぎるｗ



んで、無事すっきり二段構成に。もうこれでいいや。

てかそろそろデフォルトで再起動ボタンつけてくれないかねfirefoxさん……。
cssの更新で再起動するんだけど、再起動ボタンはアドオンの所にuserChrome.xmlで追加してるんですけど、cssの編集でミスってその辺全部非表示になったりとかすると、再起動ボタンが使えないｗ
そこで毎度、「再起動ボタン普通に要るだろ。標準でつけとけよ」となんども脳内にこだまするｗ

そんな感じで、こんなんで時間取られてファッキン。


書庫ファイルのなかの画像ファイル整理整頓編集ツール。

今回は、いままでｃ++で例外って全く使ってなかったのですが。
基本的にゲームＰＧでは例外は使わないですからね。c++1x以降はとにかくどこでもnoexcept指定。それでも例外出るようなケースは(標準ライブラリとか)即std::terminateでアプリ終了。
例外出るようなケースはゲームの続行不可能の場合が殆どなのでそれで問題ないですしね。
noexcept指定することで最適化されやすくなるので実行速度も稼げるし。

なのですが、外部のdllとか使う場合、その部分だけは例外使った方がいいんじゃないかなーと。

今回のだと、7z.dllをロードして、そこから書庫フォーマットにあわせたアクセス用のオブジェクトを取得して、そこにコールバックを設定して～
みたいな流れなのですが、その過程のエラーハンドリングのメッセージが、例外使わない場合は結構面倒だなーと。
グローバルなエラーメッセージ保持するの用意するのは、結構用意しても実際にはめんどくさくて無視しちゃうケース多いしｗ

さらには、7z.dll利用部分は静的ライブラリとして別プロジェクトに別けてるんですが、例外つかうにしても、このライブラリの中だけで完結した方がいいのか(ライブラリのなかでtry-catchする)ライブラリ利用側でやった方がいいのか。
そこいらへんで、ライブラリの設計として、7z.dllのロード部分を完璧に隠蔽して、内部でロードするクラスを用意するとしたら、そのクラスを作成する部分をtry-catchするのか、それともそのクラス内の7z.dllのロード部分をtry-catchして、そのクラス内でエラーハンドリングするのが良い設計なのか？

と、長らく例外というものをシカトし続けてたツケが……。
まったくどうやるのが定石なのかとか、設計として良いのかよくわからん～。

とりあえず、今更ながらこの辺の解説サイトみてみると、やはりｃ++においてはコストがアレなので、なるべく範囲をしぼって、さらには利用するのはその後アプリケーションが継続不可能なタイプのものにだけにするのが、面倒はおこりにくいっぽいてのが一応の結論か。

いまいち例外のコストていろんなサイトみてもよくわからない。
正常系ならコスト0とか言うけど、tryは遅いとか書かれてるところもあるし。
とりあえずループの中でtry-catchはやっちゃ行けないってのはわかるんだけども。

un7z::InArchive_ptr in = nullptr;
try {
in = un7z::InArchive::create(filePath, fm);
} catch (const un7z::Exception& ex){
qDebug() << ex.result();
return;
}
in->こっからなんかいろいろする

てのと

try {
auto in = un7z::InArchive::create(filePath, fm);
in->こっからなんかいろいろする 　
} catch (const un7z::Exception& ex){
qDebug() << ex.result();
return;
}

で、try節の中でなにかの処理をずらずらとやるのって、そっちの場合てコストはどうなん？　try節の外でやった方がええのん？
あとtry節のなかで、noexcept指定の関数呼んだときは、その関数は最適化から除外されずにコスト的に問題なくなるのか？　とか。

知りたいところの情報がなかなか出てこなくて、いまいち世の中の多くの人もあんま例外って細かいところまで知らない人の方が大多数なんじゃないのかという気さえしてくるｗ

そんなかんじであんまわからんものは無闇に使う物じゃないなということで、多層的にエラーハンドリングが必要かつここで失敗したらもうその後の処理は何にも出来ないっていう7z.dllのロードまわりだけ例外を使う事に。

でもそうすることでまた、ライブラリの作り方的な方でもいろいろと考えることがでてきちゃったりで。
そんな感じで、設計自体見直しながら、このあたりをリライトしたり。

次回は、ｚｉｐ書庫だけは自前で処理する事にしたのでその部分を組む……てか以前組んだのを移植する作業に。

んでもこの部分を書庫関係用ライブラリとして7z.dll使用ライブラリと一纏めに追加しちゃった方がいいのか……。
でもこの辺、書庫内の画像ファイルのフォーマット解析とかもやるんですよね。画像フォーマットや画像サイズ（ピクセル数）色数とか。
そういった画像関係のコードもここに含めるのは違うなーと言う気もするし。
でもフォーマット解析だけなら一応範疇なのかな。書庫内ファイルの情報って意味では。

そこいらへんで、ライブラリ利用側とライブラリ側のどっちがどこまでやるのかってところの線引きも迷い出す～