最近野菜要素としてごぼうのきんぴらを頻繁に食べているんだけど、ふと💩した後流す前に見てみたら丸々残ったごぼうが数本水面に浮いてて笑ってしまった

https://twitter.com/mi_zu_to_ra/status/1272764544427819009 #tw

ジーベン・エルフを思い出した

https://github.com/dtolnay/anyhow/blob/1089f316136a9718b6e9b5943772822958cd268d/src/error.rs#L198-L203

anyhow::Error で Box<dyn std::error::Error + Send + Sync + 'static> 相当のものの代わりに自前 vtable 使ってるの、 thin pointer を使いたいというだけの理由であれば Box<Box<dyn ..>> みたいにするというクソみてえな手もあると思った (は？)

そのようにしてないのはアロケータが重いと嫌みたいな話かな。それとも意味論的にアホっぽいから？
いや普通に考えて正気で Box<Box<T>> なんて書く人がいるとは思ってないけど、提案したらどういう理由で却下されるのかはちょっと気になる

そういえば論理今日の老人トークなんですが。

float が double より遅いという話、あれかなり outdated だったっぽいですね (調べて初めて気付いた)

x86 系 CPU の float/double - petakoneko’s diary
https://petakoneko.hatenadiary.org/entry/20060622/1150950545

float vs. double
http://herumi.in.coocan.jp/prog/prog90.html

内部的に拡張されるから double でも変わらんみたいな話は x87 命令の話で、最近の CPU は SSE2 とか AVX に float / double それぞれのスカラー用命令が入っているらしく、速度は変わらないらしい

以上、老人トークでした

常識が更新されないの、こわいね……

歴史的資料として。

Ｃプログラミング診断室／キャストが好き／float型対double型
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.4.4.html

1996年の情報です

や、 copyright 表記が1996年になってるけどコメントでは 2007年に弄られてる形跡があるな。まあいいや

libskk は vala で実装されてるので世話になってるし、なんならﾌﾟﾙﾘｺも vala で書いた

vala 、マジで「順当に進化した better C」という感じ。 C++ で消耗している場合ではない

Rust が選択肢に含まれてるなら Rust 一択ですね…… (個人の感想)

べつに姉妹なら血縁関係あっても問題なくない……？ (?)

なにもわからない
雰囲気で物を書いている

記号？

reference の & 、dereference と raw pointer の *、try の ?、pattern の |、binding の @、range の .. と ..=

メソッドとか基本的なものを抜きにすればこのくらいか？

match arm の => と関数型の -> は、まあべつに見た目通りなので

このアカウントは、notestockで公開設定になっていません。

そういう話か

for pat in expr { block }
は

{
let mut iter = std::iter::IntoIterator(expr);
while let Some(pat) = iter.next() { block }
}

の糖衣構文です (これは慣れると当然に見えてくるので、そこまで深く悩まなくてもよい)

pattern の | は普通に "OR" のつもりだと思うので、そのイメージがあればそのうち当たり前に見えてくる

直観的でないのは ? (try operator) だと思うけど、あれは大昔 try! というマクロがあった時代の話を思い出せば理解しやすいですね

std::try - Rust
https://doc.rust-lang.org/1.44.0/std/macro.try.html

try!(expr)
はだいたい

match expr {
Ok(v) => v,
// ↓ From::from(e) は e.into() とだいたい同じ
Err(e) => return Err(From::from(e)),
}

に展開されるものでした。
その代替・拡張として発生した演算子が ? で、 expr? は Result だけでなく Option とかにも使える。
Option の場合は expr? は

match expr {
Some(v) => v,
None => return None,
}

という感じになる。

クロージャの |args| expr がｳｰﾝとなる気持ちはまあわかる (左右の括弧が同じ文字なのがどうにも……)

$(( 1 + 2 )) みたいなやつね

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

わかる、 "$(cmd)" みたいにしがち

cd "$(dirname "$(readlink -f "$0")")"

とか \` で書きたくないよ……

this...

法務省：人権擁護局フロントページ
http://www.moj.go.jp/JINKEN/

いじめについて自分の近辺の動きが鈍い場合、法務省に相談するというライフハックがある。
子供たちが知っておくべき知識のひとつだね

最上階に住んでいるのにドッスンドッスン聞こえてくるので、たぶん下の階とかから壁伝いに響いているのかもしれないと思っている

Cわかる人は超越者を名乗っていいと思う

http://cppquiz.org/

楽しんでいこう

このアカウントは、notestockで公開設定になっていません。

VS で std::abort() 呼んでるのに何事もなく次のウィンドウプロシージャが呼ばれるし、そのたびに abort() を呼ぶので「ﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾛﾝ」とすごいエラー音の後にデバッグしますかのダイアログが出てきます (マジで何なんだ)

しかも abort() するのが一度だけだと、ダイアログは出るけど abort 貫通して何事もなく次のメッセージを処理しつづけるので、異常終了したはずのゲームを続けて遊ぶことができてしまう……なんだこれは

abort しろと言ったのに abort しないの、さすが C++ コンパイラつってるのに C++ 準拠してない製品を出してた会社だけあるわ (???)

まあ冗談はさておき、 SIGABRT をトラップしてデバッグに使えるのはいいとして、貫通してメッセージループを続行するのは本当にやめてくれ

プロセスを殺す仕組みがあるなら、 abort() を呼んだとき同じような挙動で死んでくれればいい (OS が殺してくれればいい) と思うわけですが……

文脈は Win32 の小さなプログラムを C++ で書いている状況です

ウィンドウプロシージャから呼んでいる同スレッドの関数で abort() しているので、そのまま本来実行継続を意図していない状態で再度ウィンドウプロシージャにエントリーしてくるのは私の意図するところではないわけですよ
(そもそも内部的な不整合を検知したから abort しているわけであって)

異常だからこそ abort してるんです

exit じゃなくて abort してるんですよこっちは……

内部一貫性が壊れたままプログラムが走るの、圧倒的恐怖しかないでしょ

そもそもプロセスを外から問答無用に殺せるということは (モダンな OS であれば当然) リソース解放も必要に応じて OS がしてくれということでもある。30年前の OS ちゃうんやぞ

たぶん Win32 API で意図したとおり異常終了させられるみたいな話もありましたが、それはそれで良いとして、であれば abort が何故そうならないのかを疑問視している

これは「エラーがあって、それが想定のうちで、かつプログラムが正気で走っている」という状況でしょう。その状態なら綺麗に後始末するのは正しい。

abort はそうではなくて、「プログラムが論理バグの存在を (内部状態の矛盾や仕様違反の検出によって) 自覚した、既に手遅れの状態」で使う自殺スイッチであって、これを使ったあとぶっ壊れ状態で更に正常系を想定したコードが続行されるなんてこと許せるわけがないんですよ

だからその「開発時に想定できなかった」マズい (実質未定義動作みたいな) 状態で使うべき abort が、なんで OS によってコールバック関数が呼ばれ続けるのを止めないのか、という話です！

このアカウントは、notestockで公開設定になっていません。

ファイルシステムの話ではないし btrfs は今日も問題なく動いてます

このアカウントは、notestockで公開設定になっていません。

そもそもプログラムが正気 (状態の一貫性や満たすべき条件) を失った時点で当人に後始末をさせるのは気休めでしかなくて、根本的には OS が強引に後片付けを引き継ぐべきという考え (OS 越しでなくハードウェアと直に対話している特殊なアプリとかは別として)

で、 OS に後片付けをする能力があるのなら、 abort が野蛮だろうが何だろうが、狂ったプロセスが後片付けをしたつもりだろうが何もせずすべてを投げ出そうが、最終的に OS がやることをやるので、であれば abort はやっぱりプロセスを速やかに容赦なく殺すべきだと思うんですよ

そもそも本当に OS の後片付けをあてにできない状況なら SIGABRT をフックしてクリティカルな後始末だけしたりみたいなことはできるはずで、 abort 後に許される処理なんてそのくらいですよ

atexit とか at_quick_exit で登録された後始末さえ呼ばないものなんですよ abort は

あーいや SIGABRT にフック付けられるかはわからないか。

これはそうでしょうけど、だからといって abort がアホであっていいことにはならないので別の話です

たとえば assert に失敗したら abort が呼ばれたりするはずですけど (規格で保証されてるかは知らん)、 assert 失敗した状態でそのままプログラム動かしていいんですか？ 下手したらハードウェアを滅茶苦茶にしたりセキュリティホールになる可能性あるわけですが

電源を抜いて PC や HDD が壊れないのは仕様の範囲外ですが、 abort で異常終了すべきなのは仕様と保証の話なので全然違うと思います

これは私とだいぶ見解が違いますね……

Panic を恐れるべからず - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2019/12/19/dont-fear-the-panic/

私は「狂ったプログラムの自称 “後始末” や自称 “復帰” を信用できる理由はないので、不整合があれば即座に殺せ」を信条にしています

もちろん人命に関わる状況とかだと話は変わってくるけど、それも設計レベルで「不整合がプログラム全体に漏れ出さないように作って、不整合があった場所はさっさと殺して再起動しろ (結果として全体が不整合に狂わされることなく動き続けるようにしろ)」となるべきであって、「気付いてしまった不整合を見なかったことにして実行を続ける」は如何なる状況でも正当化されないと考えます

なんか考えが食い違ってると思うんですが、私は「起こりうるエラーをどうするか」の話ではなくて「起こりえないエラーが起きてしまったらどうするか」の話をしています

準正常系と異常系を区別したときの異常系側で何をするのかという話になるかな

このアカウントは、notestockで公開設定になっていません。

大昔のプロセス殺したらそのままメモリリークする OS とかならさておき、現代であれば…… となりますよね

https://mstdn.nere9.help/@orange_in_space/104363686803728116

orange 氏が言ってるのはすべて準正常系の話でしかなくて、私は異常系の話をしているので噛み合っていない

「起こり得る」と認識していることはすべて想定されたエラーなんですよ。そういう話はしていない

たとえば std の vector を長さ128にリサイズした直後に容量を確認したら 64 だったりするとビビるじゃないですか。というか「物理的に可能ではあるが絶対に想定しないしいちいちチェックして if 文で対処もしない」類のエラーなわけです。
私が殺したいプロセス異常というのはそういう種類の話

このアカウントは、notestockで公開設定になっていません。

たとえば int a=non_42(); したあと宇宙線が飛んできて a が謎の値 42 になることだって実際に現実に起きうるエラーですが、基本的に皆そういうの検査しないわけですよ。1行ごとに a の値が non_42() を読んだときの値のままであることを確認しない。
そもそも a が 42 になってたからといって、元の値なんて復元できないじゃないですか。

そういう「まずありえないし、あったとしても救いようがない」状況を (自覚的であれ無自覚であれ) プログラマは必ず捨てているもので、じゃあもしその「ありえない」を見てしまって発狂したとき何をするか、という最後の砦が assert や abort なんですよ

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

結局同じことで、我々は暗黙に或いは明示的に「不変条件」とか「一貫性」というものを想定して、それが満たされているときにしか動かないプログラムを書いている。
不変条件の存在しないとはすなわちあらゆる仕様が信用できないということなので、本質的にナンセンスなんですよ。「ありえない状況」の存在しないプログラムはありえない。

このアカウントは、notestockで公開設定になっていません。

というかそのままですね

プログラムが自身の発狂を認知できる数少ない機会が assert 類であるわけで、いかに「狂ったプロセスがあらゆるものを破壊しに行くのを素早く止めるか」が大事だから assert を積極的に書けということになる

全ての不整合を検出できると思うなというのはその通りで、だからといって「物理的に可能なすべての状態を考慮せよ」というのもやはりナンセンスです。

int a = 3;
if(a!=3)
{
a=3;
}

みたいなことを書くべきじゃないんですよ (今は volatile の話はしていないよ)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

エラーに対処できるならすればいいけど、対処しようのないエラーとか、対処を考えるだけ無駄なエラーとかがあって、そのうちごく一部に「幸運にも assert とか書いとくだけで検出できるエラー」があるんですよ

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ほんこれ

お仕事でｲﾝﾄﾞｯｽﾞ使わされてるんですよ、趣味の開発でこんな環境使うわけない

それは「想定外」の種類によるのでなんとも

だから私は一貫性とか不変条件という言葉を使ってます

たとえば、人が近付くとアームを引っ込める処理があるとします。
でもアームを引っ込める処理をしたのにセンサはアームがどんどん飛び出していることを報告するかもしれない。
それでもまだ「異常事態には人に危害が及ばないようアームを引っ込めるべきだ！」といえますかね

ここでの異常とは「アームを引っ込める処理をしたのに反対の挙動になっている」というある種の論理バグの可能性が十分にあり、このとき開発者が考えるべきなのは「致命的におかしいアーム制御で、それでもどうにかアームを引っ込めてみせよう」ではなく、「これ以上動かして人やモノにぶつけると被害が大きくなるから、即座にアームを動かすのをやめよう」じゃないですかね。
それが「不変条件が満たされないことに気付いたら即座に殺せ」の意図です

もちろんアームの制御を停止したとき新たに発生するリスク (アームが固まらずに垂れるとか) もあるだろうけど、それはハードウェアとか別レイヤーで対応すべきことで、断じて「狂ったソフトウェアを使いこなしてアームを動かし続けることを試みる」べき理由にはならない

このアカウントは、notestockで公開設定になっていません。

はい、なのでとにかく「狂ったものを動かし続けるな」が意図するところです (「止める」とは「止める制御をする」ではなく「制御をやめろ」「狂った制御を発効させるな」です)

このアカウントは、notestockで公開設定になっていません。

「回避処理自体も何らかの『想定』のもとに動いていることがあって、その『想定』が既に満たされていない状況を考えないといけない」という話です (回避がうまくいくことが信じられるなら回避を試みればいい)

https://mstdn.nere9.help/@orange_in_space/104363873084252780

これは「非常用発電にはメインの原子炉のプログラム稼働状態の破綻が伝播しない」という前提では正しいでしょうね。
というか、そういう設計にすべしという話でもあるんですけど

私が言っているのは「プログラムが一貫性を失ったとき、その破綻は他の部分へ伝播している可能性が高く、特に復帰処理もその破綻した一貫性や前提条件に依存していたり修復自体ができない場合が多い」という話。
一貫性破壊が伝播しない設計ができるならそうした方が異常に強くなるのは、当然それはそう。

このアカウントは、notestockで公開設定になっていません。

そもそも伝播しないなら別プログラムでよくない？という話もあるよ
(同じプログラム内である以上、何らかの形で状態を共有しているという想定は自然だし、その共有状態が壊れていたとき「壊れていない意味のある部分」がどれだけ残るのかという悲観が前提にある)

だから「どういう “異常” なのか」次第なので、一口に「異常」と言われてもそんなのケースバイケースです

このアカウントは、notestockで公開設定になっていません。

そういう意味か。
私は制御ソフトウェアの話をしてましたが、まあアームのハードウェア側でやることやれよとかいろいろいえるか

このアカウントは、notestockで公開設定になっていません。

たとえそれがファイルシステムやデバイス側の異常に見えたとしても、ですか？

根本的なマインドとして「手に負えなくなっているなら、これ以上余計なことをするな」というのが abort レベルの異常終了なので、「うんうんそういうこともあるよね、 exit(2) します」とかの終了とは状況のマズさが違うわけです

ちなみに迂闊にファイルをフラッシュしようとすると I/O が永遠にブロックしてプロセスが終了しなくなるなどの場合が現実にあります (というかそれでつらい思いをした)

それはコンパイラのバグとか OS の sanity についても同様のことがいえて、結局抽象すると「下のレイヤーが『期待したとおり』動いてくれる (或いは『エラーを検知して対処できると信じている』) という前提条件が破られない想定をしている」という話なので本質的な差があるとは思いません

たとえば「標準ライブラリは仕様通りに動く」とかもそういう暗黙の前提条件のひとつで、我々はそれを「信じないことができる」

OS も機械も同じで、我々はあらゆる想定を「信じないことができる」が、それでも内心いくらか信じている。信じていないと意味あるプログラムが書けない (意味論のないプログラムに意味はないので)。

で、その「信じている部分」に裏切られることがある、という話が前提条件が破れるという言葉の意味です

このアカウントは、notestockで公開設定になっていません。

「信じていない部分に裏切られた」なんてのは最初から想定内で、そんなのさっさとエラーに対処しろでおしまいですよ

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

最初の文脈に戻りますが、「アプリ開発者による『これはもう駄目だ！』という表明を信用しない」というのが OS の思想であるというのならそうですねという感じだけど、その帰結が「大丈夫！ 駄目だと思うから駄目なんだ！ まだいけるぞ！」と死体に鞭打って破綻したプログラムを走らせ続ける凶行であるというのが、ちょっと信じられなかっただけです

このアカウントは、notestockで公開設定になっていません。

wndproc だけが破綻しているという考えはわからない。
「wndproc がアクセスできる情報を共有している部分のいずれかが破綻している」が論理的に正しい想定だと思うんだけど

というか、そこで楽観するなら assert しなければいい話なので、 assert 失敗したら悲観的な対処になるのは自然ではある

このアカウントは、notestockで公開設定になっていません。

「狂った本人が過去に『俺がこうなったら殺してくれ』と言っていた」というのと「せんせー、この人もう狂ってます！」というのと、 assert はどちらにも使われる可能性があるという想定ってそんなに不自然でしょうか。

そもそも不整合は未知のバグにより起きたりするわけで、未知であるがゆえに当然「どこが狂ったせいで共有状態が破綻したのか」はわからないわけですよ。
であれば、 assert や abort による破綻がその呼び出し元ローカルであると考える合理性はない

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

「本人かどうかはわからないが、少なくともプログラムのどこかは (対処困難な形で) 壊れている」という報告なんですが、「よし、ならお前以外は大丈夫だな！」とはならないのではという

狂っているのが本人かどうかはわからない場合も多いし、わかっていたとしてすべきことが変わるとも思えない (何故ならその破綻は既に伝播しているかもしれないと考えるべきなので)

https://mstdn.nere9.help/@orange_in_space/104364049252675923

「破綻したデータを食う前に処理を止めろ」には同意するし正しいけど、それは「破綻を発見したとき、既に他の誰かがその破綻を発生させていて、自分より前にそれを誰かが食っていない保証がない」という視点が欠けている

もちろん「プログラムのすべての部分を掌握しているので、いかなる部分も他所で発生した破綻に巻き込まれない確信がある」というのならそれでもいいけど……それは原則として過信だと思いますね (人間そんなに強くない)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

wndproc の方に特殊事情があるのか……

つら

だから、それを自分が完璧にできているということを信じられないという話をしています

たぶん究極的には「プログラマが十分に賢いことを信じられるか否か」になりそうですが、これについて私は「開発者を含め人間はどんなに注意しても間抜けなミスをするし、その確信を信じきることはできない」という立場です

「プログラムを完璧に正しく書きました！ エラー処理も万全です！」と主張する人がいたとして、そんなの信用しませんよ……

あーそういう話、やっと理解しました

私の認識ではウィンドウプロシージャもプロセスの一部という認識だったので当然同時に即死すべきだと思っていたけど、あれは Windows 側に全権があってプロセスが最優先で持っているものではないみたいな考えがありえるという話でおk？

「プロセスが終了するとき細々したデータ構造を free してたらそれだけでめっちゃ時間かかるので、 free しないで OS 側にまとめて開放させた」みたいな感動の実話を聞いたことがあります (具体的なことが思い出せないけど、少なくとも「なんじゃこの素人は」と思わなかったのは確か)

そもそもうまい設計してたらリソース解放なんてそうそう明示しないけど……

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

RAII のようなパターンで自動化せよ、「このリソースは不要なので忘れず解放しとかないと！」みたいなことを手動でやらないといけない時点で error-prone なので言語やフレームワークや設計の側に改善の余地がある、という話です

それをフレームワークとか言語でやらない、できないということならその状況に問題があるという話です
(もちろん熟慮の上で敢えて手動管理したりする選択肢はあるべきだけど)

人間は誤るものだし、だからこそ「正しいコードを書きやすく、間違ったコードを書きにくく」という原則には価値がある

error-prone なものがあったとして、「だから人間は注意しないと！」というのは間違ってはいないけどｽﾞﾝｽﾞﾝ進むべき方向ではない。
「間違いようのない仕組みにしよう」に行くべきなのであって、そして現実にそれはある程度可能なのであって。
「ヤベー事態でもちゃんと解放しないとリソースがリークすることが！」と言われても、そりゃ設計が残念なのではとしか……

GC がなくても自動的なリソース管理はできるので……

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

退勤マンと化した

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

いやこれさっきからずっと言ってるんですが、 orange 氏のしてる話は「想定外を潰して想定内に持ってきましょう」という、準正常系で扱う範囲を広げる話をしていて、私は異常系として捨てることに決めた可能性をどう扱うかの話をしているので、結局噛み合ってない

結局「予定外の事態でも検査して対処するのを積み重ねて『想定内』に引っ張り込むのを沢山繰り返すしかない」という話に聞こえるんですよ。
私が考えているのはそういう努力とは全く別の部分で、「復帰すべきでないと定めた異常をどう『扱わない』か」です

復帰の努力はできる、でもその努力が実るとは限らない、あるいはその努力がコストに見合うとは限らない、そういう辺りの線引きが揺れる話はそれこそプログラムの利用分野や要求次第なわけで。
どこに線を引くかと、線のむこうとこちらでどういうスタンスをとるべきかというのは分けて考えられると思っているので

(まあ私が internal inconsistency を完全に abort 側にあるとした線引き自体に異議があるという話かもしれないので、それは話の展開がよろしくなかったとは思う)