><https://twitter.com/orange_in_spacehttps://pawoo.net/@orange_in_space
これはそうでしょうけど、だからといって abort がアホであっていいことにはならないので別の話です
PCの電源切りたい時に電源プラグ引っこ抜いて「いきなり電源落ちても壊れない頑丈なファイルシステムを使ってるからだいじょうぶ! いつもこうしてる!」みたいな感じに感じる><; 「そりゃファイルは壊れないかもしれないけどでも・・・・><; 」的な><;
完全にどうしようもない状況であればたしかにそうかも><;でもWindows用のアプリの場合、例えばメモリを確保できなかったとか、GUI等のリソースがOS側の都合で破棄された等の場合程度であれば、OS側の異常終了の機能に頼るべきではないかも><;
そもそもプログラムが正気 (状態の一貫性や満たすべき条件) を失った時点で当人に後始末をさせるのは気休めでしかなくて、根本的には OS が強引に後片付けを引き継ぐべきという考え (OS 越しでなくハードウェアと直に対話している特殊なアプリとかは別として)
それはごもっともだけど、でも非同期な部分がある環境のソフトウェアでそんな野蛮な方法で止めるの問題があるかも><;
だからその「開発時に想定できなかった」マズい (実質未定義動作みたいな) 状態で使うべき abort が、なんで OS によってコールバック関数が呼ばれ続けるのを止めないのか、という話です!
であれば、『異常な状況に陥ったっぽいフラグ』を用意してそれをたてるようにして、各所でそれを見て処理を抜けるように書くようにしないと、シングルスレッドなソフトウェアではどうにかなんとかなっても、マルチスレッドなソフトウェア(Windows用に普通に書けばそうなる)ではわりと大変なことになると思う><
これは「エラーがあって、それが想定のうちで、かつプログラムが正気で走っている」という状況でしょう。その状態なら綺麗に後始末するのは正しい。
abort はそうではなくて、「プログラムが論理バグの存在を (内部状態の矛盾や仕様違反の検出によって) 自覚した、既に手遅れの状態」で使う自殺スイッチであって、これを使ったあとぶっ壊れ状態で更に正常系を想定したコードが続行されるなんてこと許せるわけがないんですよ
ほんとのほんとのほんとのほんとに、どうっっっしてもどうにもなら無い場面以外では、正常に終了するように書くべきかもというか、異常終了はあくまで、開発時に想定出来なかった異常により終了する場面で起きるものと考えるのがWindows流だと思う><
異常だからこそ abort してるんです
あと、GUIでイベントドリブンなコードの場合は、終了させたい時は『「終了してね!><」フラグ』をたてておいてそれ監視するみたいに書く方が普通だとオレンジは思ってた><(別スレッドも『終了してねフラグ』が立ってたら「あ、もう要らないのか」って判断して処理スキップするように書いたり><)
GUI使ってるのであればリソースの解放処理が必要かも?><
ウィンドウプロシージャから呼んでいる同スレッドの関数で abort() しているので、そのまま本来実行継続を意図していない状態で再度ウィンドウプロシージャにエントリーしてくるのは私の意図するところではないわけですよ(そもそも内部的な不整合を検知したから abort しているわけであって)
文脈は Win32 の小さなプログラムを C++ で書いている状況です
プロセスを殺す仕組みがあるなら、 abort() を呼んだとき同じような挙動で死んでくれればいい (OS が殺してくれればいい) と思うわけですが……
よくわかんないけどちゃんと処理抜けて必要な終了処理して終了するように書けばおkだと思う><自プロセス殺してまでして終了ってかなり異常な状況っぽさ><
ファイルもGUIも何も使わない小さなコマンドラインなアプリとかなら別だけど、ものすごくレアケースっぽさ><
あと、Windowsのソフトウェア作るのに、異常終了させるのはダメだと思う><;UNIXはどうだか知らないけど、論理的に異常終了させる場面であっても、ほんとにOSの異常終了が起きてしまうのは、ほんとに異常というか非常事態であると考える方がいいかも?><;ちゃんと終了処理をしないとダメかも><;
全部UNIXでおkって人(Matz氏とか)なら気にならないんだろうけど><
うん><; なのであちこちUNIXというかPOSIX前提すぎて「そんな1970年代にテクノロジーじゃなくもっとモダンなOSを使うんだよ!><# 」ってなる時に邪魔になる部分多いと思うし、UNIX依存部分は明確に分離して欲しさがある><(よりモダンな環境や逆にチープな環境ではその部分無視しようってしやすく><)
思考の /dev/null