Rust part26 (814ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) ﾚｽ栞 あぼーん
730: 11/10(日)16:41 ID:tFJCBt9m(1/13) AAS
>>728
キレるはともかく最初からelision rules貼ればよかった説は確かにそう、残念ながら二回目の機会がないが次はそうしてみるぜ
でもよお……こんなのrust-analyzerが完璧なinlay hint実装してくれりゃやらなくて済む話でもあるんだぜ
737(1): 11/10(日)19:59 ID:tFJCBt9m(2/13) AAS
質問の答えになってないし、組み込み環境で「プログラムが終了」したり、「管理している全メモリを解放」できるアロケータが必要などとまで言い出した
いやはや
738(1): 11/10(日)20:16 ID:tFJCBt9m(3/13) AAS
>>735
>>661に適当にこれだけのmain足してvalgrindかけてみた
fn main() {
let s = "2021/07/04";
let (year, month, day) = yyyymmdd(s).unwrap();
println!("{}-{}-{}", year, month, day);
}
外部ﾘﾝｸ:pastebin.com
まあ、リーク扱いで出るよね
こういうのがあんまり多いとマジのリークと区別付きづらくて大変そうだけど、なんかアノテーションみたいなので対策できたりするのかな？
742(1): 11/10(日)20:53 ID:tFJCBt9m(4/13) AAS
相変らず単語ひとつひとつが独自用法すぎて解読が困難だね
mallocみたいなグローバルアロケータを自分で実装しようという話をしているのか？
それとも（allocator_apiがいまだにunstableなせいでボイラープレートモリモリ書かされる）typed_arenaやbumpaloのようなカスタムアロケータの話をしているのか？
前者だとしたらバッファという言葉が出てくるのがまず分からない、もしかしてヒープ領域全体のことをバッファと呼んでいて、確保/解放はsbrkのことを言っているのか？
後者だと「管理してるメモリの全解放」ですべての内容のDropしないといけなくて……って考えるとどう考えてもゲロクソむずいけど、全オブジェクトをManuallyDropに包んで返して責任放棄するのかな……
743: 11/10(日)20:56 ID:tFJCBt9m(5/13) AAS
>>741
できねーもんはできねーんだから適切な道具を使うんだよ、笑うならそこの嘘吐き宣教師を笑うんだな
745(1): 11/10(日)21:16 ID:tFJCBt9m(6/13) AAS
>>744
んでどっちのアロケータの話をしてるの？って
747(1): 11/10(日)21:35 ID:tFJCBt9m(7/13) AAS
>>746
グローバルアロケータの話をしてんのか、カスタムアロケータの話をしてんのか、って聞いてんだよ
自分の頭の中の理屈をダンプするんじゃなく、言葉の定義をすり合わせる努力をしろ
748: 11/10(日)21:41 ID:tFJCBt9m(8/13) AAS
少なくともvalgrindとかperfmonみたいなやつは、プログラム終了時にヒープを辿って解放済みマークの無い場所を見つけたらリークって報告するんだし、一般的にはそれがリークだよ
プロセス終了時にメモリマップの割り当てが解除されるとか、どうでもええわ
751(1): 11/10(日)22:15 ID:tFJCBt9m(9/13) AAS
> プログラム終了後にメモリリークが起きうる組み込み環境
組み込みやったことないから知らんけど、そんな環境があんの？
752: 11/10(日)22:27 ID:tFJCBt9m(10/13) AAS
外部ﾘﾝｸ:github.com
組み込みの典型的なコードってこのREADMEのサンプルコードみたいなんでいいのかね
プログラム(main)は終了しない
ヒープの「解放」処理も無い
合ってるよな？
自由に使える物理アドレス空間の一部を実行時アロケーションのために使用するってだけなら、使い終わりにやる「解放」の処理というのは何の話を言ってるんだ？ って思ってたけど
そんなものはない、で合ってるのよな？
753(1): 11/10(日)22:31 ID:tFJCBt9m(11/13) AAS
>>750
search first
756: 11/10(日)22:48 ID:tFJCBt9m(12/13) AAS
>>754
> そういう特殊な環境を出してるのは俺ではないからね
あれ、そうだっけって思って辿ってみたら言い出してたの>>604だったわ
やっぱお前じゃねーか複おじ
プロセスにしろ組み込みのプログラムにしろ、OSだかシステムファームウェアだかの外部の管理者的存在が行儀の悪いやつのケツを拭いてくれてるだけのことを、
常識的のあるプログラマは「リークしていない」とは言わないんだよ
758: 11/10(日)23:16 ID:tFJCBt9m(13/13) AAS
えーではリークの定義に関して直接的反論はなしということで
以下はすべて誤りであったということでよろしいですね
対戦ありがとうございました
>>593「freeせずにプログラムが終了したり落ちたりしてもメモリリークは起きない」
>>604「freeを忘れてもあるいはfreeせぬまま異常終了となってもその仕組みによりメモリリークは起きない」
>>631「そしてfree()せずにプログラムが終了してもメモリリークは起きない」
>>744「sbrkのあるOS環境ならsbrkでOSへ全メモリを返還できるのはその通りだがそれをしなくてもプログラム終了後にメモリリークは起きない」
>>746「普通の仮想メモリOS環境ならstaticでもBox::leakでもプログラム終了後にメモリリークは起きない」
「そうでない特殊なOSや組み込み環境ならばそれ用に用意するメモリアロケータをプログラム終了直前に呼び出して全メモリ返却させればメモリリークは起きない」
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.204s*