Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part25
https://mevius.5ch.net/test/read.cgi/tech/1722354386/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/11/08(金) 20:12:43.27

>>669
正規表現パターンに変数やその式を使ったことないのかい？
それら式を用いるとコンパイル結果を自分でキャッシュ管理しなければならなくなる

具体的にはregex literalの有無で
(1) 無い言語の例としてPythonは効率化のためにはre.compile(パターン, ...)結果のキャッシュが必要
(2) 有る言語の例としてRubyは式を含む場合のみ毎回評価し直すためキャッシュが必要
(3) 有るがパターンに式を書けない言語の例としてJavaScriptはnew RegExp(パターン, ...)結果のキャッシュが必要

いずれもregex literalの有無に関わらずコンパイル結果のキャッシュが必要となる

**デフォルトの名無しさん** · 2024/11/08(金) 20:55:31.49

ものによるが暗黙にキャッシュする (プログラマが保存しないでよい) 言語処理系は存在するよ。

**デフォルトの名無しさん** · 2024/11/08(金) 21:02:51.24

むしろ、コンパイルしてないほう（Arc<String>）をキャッシュする
そのStringが生きている間だけコンパイル結果を生かしておく

キャッシュが必要ならArcが必要と判明したせいでGC界隈の常識が覆された

**デフォルトの名無しさん** · 2024/11/08(金) 21:23:43.02

>>672
暗黙にキャッシュは固定文字列パターンの時だけではないか？
パターン内の式の値が毎回替わりうる可能性があるから
言語側としては>>671のように毎回評価し直す仕様や
regex literalを用いず明示的にコンパイルする関数を呼ぶ仕様になっている

**デフォルトの名無しさん** · 2024/11/08(金) 21:40:49.75

>>674
いや、キャッシュというかいわゆるメモ化かな。
入力される値は変わりうるが、同じ入力に対しては同じ結果であることは保証される (かつ現実的な用途では同じ値が入力される可能性が高い) ので値とセットで記憶しておく方法で十分に処理コストを減らせる。

**デフォルトの名無しさん** · 2024/11/08(金) 21:58:06.73

全く異なるユースケースを持ち出してまで
「どの言語も同じ」ということにしたいらしい

**デフォルトの名無しさん** · 2024/11/08(金) 22:27:14.73

>>674
Pythonのreなら直近の512個まで自動的にキャッシュされてるよ

**デフォルトの名無しさん** · 2024/11/08(金) 22:28:21.24

ワンライナーみたいな使い方をする言語では (結果的に無駄になってでも) 暗黙に色々やっといてくれるほうが便利ってこともあるからどんな言語でも Rust と同じ方式のはずとは言えんわな。

**デフォルトの名無しさん** · 2024/11/08(金) 23:01:18.69

>>673
Arcは要らない
何度も使う固定の正規表現ならその関数かモジュールのstatic変数で十分
変数部分を持つ正規表現それぞれを何度も使い回すならその呼び出したい元の構造体フィールドに入れておけば十分

>>675
そんな一般的なメモ化は論外
ハッシュマップ相当のコストがかかる上に再利用しないものや不要になったものを持ち続ける愚かさ

**デフォルトの名無しさん** · 2024/11/08(金) 23:54:55.29

>Arcは要らない
ふーん

https://docs.rs/regex/latest/src/regex/regex/string.rs.html#101-104

**デフォルトの名無しさん** · 2024/11/09(土) 00:23:52.73

それはRegexの内部実装なので無関係だね
CloneできるようにArcを使ってるよくある手だよ

**デフォルトの名無しさん** · 2024/11/09(土) 01:08:06.88

？
内部実装の話をしてるんではないのか

**デフォルトの名無しさん** · 2024/11/09(土) 01:20:28.66

再コンパイルを避けるためにstaticで持ったりオブジェクトメンバーで持ったりと利用プログラマー側の話でしょ
その時に必要ならCloneもできるということ

**デフォルトの名無しさん** · 2024/11/09(土) 01:27:01.06

何の話をしてるのか、誰か一人でも分かってるんだろうか

**デフォルトの名無しさん** · 2024/11/09(土) 04:13:52.23

>>679
「言語はどれも正規表現のコンパイル結果を記憶する処理はプログラマの責任」に対しての「そうではない」という実例が挙げられたのであって、良し悪しを論じる文脈ではない。
なにが言いたいのだ？

**デフォルトの名無しさん** · 2024/11/09(土) 05:26:31.68

話の流れが良く分からないけど、つまり正規表現をconst文脈でコンパイルできないRustはクソってこと？

**デフォルトの名無しさん** · 2024/11/09(土) 09:50:01.85

単に複オジがクソだってこと

**デフォルトの名無しさん** · 2024/11/09(土) 12:02:14.96

いわゆるlet over lambdaがなかった時代には
static over fn
だったという話

**デフォルトの名無しさん** · 2024/11/09(土) 12:56:57.97

コーディング時に確定できる静的な正規表現と
実行時にならないと確定できない動的な正規表現は
用途も違うしプログラム内での扱い方も全然違うよね

前者が他言語なら正規表現リテラルでRustならstaticを使う分野
後者は普通staticは使わない(immutableなのかmutableなのかでまた少し違う)

Javaでstaticというのは前者だろうな
後者でも使えなくはないけど純Java脳の人は違うやり方をするはず

**デフォルトの名無しさん** · 2024/11/09(土) 13:21:26.67

いつになったら、Rustで正規表現をconst文脈でコンパイルできるようになるの？
原理的に見込みない話？

**デフォルトの名無しさん** · 2024/11/09(土) 14:07:10.40

ヒープの話に戻るが、サイズが静的に確定すればヒープを一切使わない保証もできる

**デフォルトの名無しさん** · 2024/11/09(土) 14:59:50.94

>>690
マクロ使えばできるが大変なので誰も作らない
言語に組み込まれるのは良くて20年後やろな

**デフォルトの名無しさん** · 2024/11/09(土) 15:06:22.46

>>690
https://github.com/rust-lang/regex/issues/913
クソ面倒なうえに劇的な効果があるわけでもなさそうだからやらねーとのこと

**デフォルトの名無しさん** · 2024/11/09(土) 15:09:47.03

>>693
失望した
別の正規表現クレートが誕生するのを待つしかないのか

**デフォルトの名無しさん** · 2024/11/09(土) 17:12:28.10

>chronoのようなほとんどのプログラムで使われない機能を
こういうことを書くやつに限って>>661みたいなコードを書いちゃうんだよなぁ
そういう時代じゃねぇだろっつーの

**デフォルトの名無しさん** · 2024/11/09(土) 17:13:55.79

願望は笑いものになるが失望はそうでもない
前者は単独犯で後者は不特定多数だからだ

**デフォルトの名無しさん** · 2024/11/09(土) 17:22:40.75

正規表現の単なる説明例じゃないのか
しかも正規表現自体も単なる例でstaticに突っ込む話の説明例だろ
そもそもの話はヒープをプログラムの最後まで解放しなくていい話でstaticはその一例として出てきただけだよな
一番どうでもいい末節の正規表現で騒いでいて違和感

**デフォルトの名無しさん** · 2024/11/09(土) 17:29:31.37

>>693
読んでみたが機能充実(制限)と実行速度とバイナリサイズのどれを優先するかもしくはどの二つまで両立させるかで
どのエンジンやどんな中間表現やどこまで機能制限を行なうかのバリエーションが多すぎるようだ
万人の矛盾した要求を全て満たす万能なものを実現するのは不可能だから別々に叶えるしかないな

**デフォルトの名無しさん** · 2024/11/09(土) 18:03:48.00

>>690
RustのconstってC++のconstexprだよな
どうやってヒープ領域を返すんだ？
C++だとconstexprの計算中はnew/deleteでヒープを一時利用できるけど
deleteせずに返すのはできないよな

**デフォルトの名無しさん** · 2024/11/09(土) 18:14:19.13

正規とか文脈自由とかいうのは仕様のバリエーション
実装のバリエーションなど知ったことではない

**デフォルトの名無しさん** · 2024/11/09(土) 22:22:44.34

>>697
例として出したものが
正規表現リテラルの代替策な上に
内部実装の都合上ヒープを確保してるだけで
本来はヒープである必然性もない

機能不足の代替策として
プログラムの最後まで開放しないような
ヒープの使い方もあるだろうという話なのか？

**デフォルトの名無しさん** · 2024/11/09(土) 23:06:21.72

ロックして解放してロック解除しなければいい

**デフォルトの名無しさん** · 2024/11/09(土) 23:11:14.97

>>701
基本的な知識を身に着けろよ
正規表現を内部コードにコンパイルして持つ役目がRegex構造体
可変長になるのでVecで持っていて当然ヒープは必須

**デフォルトの名無しさん** · 2024/11/10(日) 00:07:10.13

>>703
それは現状の内部実装上の都合の話
本質的にヒープが必須という話ではない
文字列リテラルにヒープが必須でないのと同じとでも言えばわかるかな？

**デフォルトの名無しさん** · 2024/11/10(日) 02:33:30.98

は～～～～キレそう

**デフォルトの名無しさん** · 2024/11/10(日) 02:34:34.55

なんの意味があんねや、このスレ

**デフォルトの名無しさん** · 2024/11/10(日) 02:36:54.54

Rustプログラマにとって有益な情報はこれ以上出ないし、まともなRustプログラマは全員逃げたことが確定して久しいので
次スレあたりから「Rust vs 世界中の全言語 Part27」とか「複製おじさんと遊ぼう Part27」とかにしましょっか
他にもスレタイ案募集

**デフォルトの名無しさん** · 2024/11/10(日) 06:48:35.70

>>704
おまえバカだろ
正規表現パターンは実行時に確定してコンパイルサイズも実行時に確定し上限サイズはわからない
ヒープは必須だ

**デフォルトの名無しさん** · 2024/11/10(日) 11:17:24.55

入力がコンパイル時に確定してるならサイズも確定するでしょ
理屈としては以下のようなものは作れると思う

struct CompTimeRegex<const N: usize> {
　data: [u8; N]
}

// 正規表現オブジェクトをコンパイル時に計算
// サイズは入力に応じて変わる
// 入力はリテラルのみ
let r = make_regex!("+\\d");

面倒だし、それでパフォーマンスが劇的に良くなるわけでも無いだろうから必要性は微妙なところ
詳しくないけど、手続きマクロの中なら計算のためにヒープを使うこともできるよね？

**デフォルトの名無しさん** · 2024/11/10(日) 11:58:38.78

BurntSushiのベンチ結果見た？

**デフォルトの名無しさん** · 2024/11/10(日) 12:03:57.56

それは入力固定で出力の型も別仕様の別の話だな
regex::Regexは実行時に正規表現が作られてもよく
それをコンパイルするためヒープが
使われている

**デフォルトの名無しさん** · 2024/11/10(日) 12:23:01.33

正規表現をコンパイルするのと比べてヌル代入を許容するのは極めて容易で
ヌルを代入すればヒープが解放される

**デフォルトの名無しさん** · 2024/11/10(日) 12:27:06.24

const文脈って、実際今なんか有効な活用されてるの？

**デフォルトの名無しさん** · 2024/11/10(日) 12:30:28.79

ちなみにzigの似た機能は有効活用されまくり

**デフォルトの名無しさん** · 2024/11/10(日) 12:38:27.50

ぐちゃぐちゃできるとかできない言ってるが自分で実装する気のある人間は一人もいねえんだろ？？？
だったら終わりだよ

**デフォルトの名無しさん** · 2024/11/10(日) 13:02:04.64

>>711
だから>>709はCompTimeRegexという従来のRegexではない型を作って話を展開してるわけ
ちゃんと読めてる？

**デフォルトの名無しさん** · 2024/11/10(日) 13:06:11.38

意図的な誤読、ストローマン論法、誰もがわかりきった説明を脈絡無く貼って議論を拡散させる
マジで不毛

**デフォルトの名無しさん** · 2024/11/10(日) 13:11:04.55

結局さ
ヒープは全部開放しなさい派閥は>>661のコードでRegex内部のArcが未解放のままプロセス終了するのは、ええんか？？ええんか？？どうなんだオラ？？って話ってことでええんよな

**デフォルトの名無しさん** · 2024/11/10(日) 13:16:48.60

>>716
全く別の話であり、これまでのregex::Regexについての話への言及・反論にはなっていないことを自覚できているならそれでよろしい

**デフォルトの名無しさん** · 2024/11/10(日) 13:18:41.74

>>718
Rustの標準ライブラリstdは
プログラム終了時に自動的にメモリが解放されるようなまともなOS環境を対象にしていて区別しているので大丈夫
OS無しの組み込み環境では#![no_std]を宣言してcoreライブラリのみサポートされる中でのプログラミングを行なう

**デフォルトの名無しさん** · 2024/11/10(日) 14:48:06.15

>>707
みんな何処に逃げた？

**デフォルトの名無しさん** · 2024/11/10(日) 15:04:06.89

>>661
スコープを外れた場合と同じようにモジュールがアンロードされる際にデストラクトされる

**デフォルトの名無しさん** · 2024/11/10(日) 16:19:33.44

>>720
OS側でプロセスを終了させる際にメモリマップを捨てる処理のことを「解放」って呼んでるから君と君以外で話がすれ違うんだと思うよ

**デフォルトの名無しさん** · 2024/11/10(日) 16:24:01.76

あと、ええんかオラ？ってのは俺の直接の質問ではない、それに答えられてもへえそうですか
元の議題は>>661、さらに遡れば>>593であって、議題内容はそれでよいか？という確認をしているだけだ

**デフォルトの名無しさん** · 2024/11/10(日) 16:26:17.63

>>721
非匿名でまともな交流ができるコミュニティかもね
rust-jpのzulipとか、あるいは英語を頑張って公式コミュニティとかに行ったか、発言しなくてもROM専してるかも

**デフォルトの名無しさん** · 2024/11/10(日) 16:30:14.58

5chで聞くよりもChatGPTの方が適切な回答をくれると思う
Rustに限らず他の言語でも

**デフォルトの名無しさん** · 2024/11/10(日) 16:34:57.50

ChatGPTもついでにCopilot Chatもゴミだよ
省略されたライフタイムの展開が自分でやったのが合ってるか自信がなくて、試しにやらせてみたらメチャクチャなことばっか言いやがった挙げ句、キレてthe Refrenceのelision rulesのところをペタペタ3回くらいコピペしたらすみません間違っていました、何度も申し訳ございません言いながらやっと正解を返してくれた
決定論的な問題を解かせるのにはまったく向いてない

**デフォルトの名無しさん** · 2024/11/10(日) 16:36:43.08

>>727
最初からキレて始めればいいのでは？

**デフォルトの名無しさん** · 2024/11/10(日) 16:39:08.93

英語が話せる人はこっちに移住しよう！！！できない人もDeepL片手にカモン！！！
https://www.rust-lang.org/community

日本語コミュはこちら！！！ってかいい加減放置されきった翻訳版の責任者のケツ叩きに行こうぜ！！！
https://rust-lang-jp.zulipchat.com/

**デフォルトの名無しさん** · 2024/11/10(日) 16:41:30.83

>>728
キレるはともかく最初からelision rules貼ればよかった説は確かにそう、残念ながら二回目の機会がないが次はそうしてみるぜ
でもよお……こんなのrust-analyzerが完璧なinlay hint実装してくれりゃやらなくて済む話でもあるんだぜ

**デフォルトの名無しさん** · 2024/11/10(日) 16:42:25.60

およ？ ID変わった
ID:OGC8ujy2=ID:tFJCBt9mです

**デフォルトの名無しさん** · 2024/11/10(日) 16:53:56.32

>>722
staticはdrop呼ばれない

**デフォルトの名無しさん** · 2024/11/10(日) 17:11:30.76

C++ で static オブジェクトの初期化順 (解体順) は問題を起こしがちだし、いっそそのへんは取り扱わないというのも妥当な判断のひとつではあるわな。

**デフォルトの名無しさん** · 2024/11/10(日) 17:43:15.44

自動化をあきらめることは賛成
だが手動で解放する技術を不要な技術と見なすことには反対する

**デフォルトの名無しさん** · 2024/11/10(日) 18:43:44.99

StringやVecみたいなヒープを使う型をstaticで管理させた場合って、valgrindみたいなメモリリーク検出ツールに引っかかったりする？
dropが呼ばれなくても終了時に一応はメモリ解放してるのか、それとも本当に何もしていないのか

**デフォルトの名無しさん** · 2024/11/10(日) 19:15:15.74

>>733
Rustならstatic変数初期化はOnceLockやLazyLockでマルチスレッド競合を含めて安全に初期化できる
static変数でdropはプログラムの終了時も起きないがメモリ解放問題は普通のOS環境では関係ないため問題ない
どうしてもdropしたいなら例えばOptionで包んでtake()で取り出すなどで手動drop()が可能

>>735
手動dropしないならばヒープ領域を持っていても解放されない
これはBox::leak()などで意図的にメモリを解放しないようにした場合でも同様
普通のOS環境ならこれでも問題は全く起きないが
組み込み環境などで確実にメモリ解放したいならば用意するメモリアロケータで対応する
つまりプログラム終了時にメモリアロケータを呼び出して管理している全メモリを解放させればよい

**デフォルトの名無しさん** · 2024/11/10(日) 19:59:43.87

質問の答えになってないし、組み込み環境で「プログラムが終了」したり、「管理している全メモリを解放」できるアロケータが必要などとまで言い出した

いやはや

**デフォルトの名無しさん** · 2024/11/10(日) 20:16:38.46

>>735
>>661に適当にこれだけのmain足してvalgrindかけてみた

fn main() {
let s = "2021/07/04";
let (year, month, day) = yyyymmdd(s).unwrap();
println!("{}-{}-{}", year, month, day);
}

https://pastebin.com/UN84vEFb

まあ、リーク扱いで出るよね
こういうのがあんまり多いとマジのリークと区別付きづらくて大変そうだけど、なんかアノテーションみたいなので対策できたりするのかな？

**デフォルトの名無しさん** · 2024/11/10(日) 20:28:05.31

>>738
サンクス
過去にC++で似たようなケースで顧客から「あなたの所のライブラリを使うとメモリリークが検出されるんだけど？」って指摘されたことがあって気になった
説明して伝わる相手なら良いけど、そういう面倒な人からのクレームを避けたい場合はstaticは避けたほうが良さそうだな
本質的には重要な問題でないと思うけども

**デフォルトの名無しさん** · 2024/11/10(日) 20:28:35.21

>>737
組み込み環境であろうとなかろうと各プログラムは終了する
さらにOS環境でOS内であっても各カーネルモジュールのプログラムはアンロードで終了する
一方でもし完全にモノリシックな一つのシステムなら終了後をそもそも考える必要がない

メモリアロケータについては自作したことあるなら管理してるメモリの全解放なんて楽勝だと理解できるだろ
割り当て用に確保しているバッファを返却するだけだ

**デフォルトの名無しさん** · 2024/11/10(日) 20:52:25.18

お前ら、Rustでプログラム書いた後にvalgrind ってるの？
もうそういうの終わりにしたいからRust使ってるんじゃないの？

**デフォルトの名無しさん** · 2024/11/10(日) 20:53:16.70

相変らず単語ひとつひとつが独自用法すぎて解読が困難だね

mallocみたいなグローバルアロケータを自分で実装しようという話をしているのか？
それとも（allocator_apiがいまだにunstableなせいでボイラープレートモリモリ書かされる）typed_arenaやbumpaloのようなカスタムアロケータの話をしているのか？

前者だとしたらバッファという言葉が出てくるのがまず分からない、もしかしてヒープ領域全体のことをバッファと呼んでいて、確保/解放はsbrkのことを言っているのか？
後者だと「管理してるメモリの全解放」ですべての内容のDropしないといけなくて……って考えるとどう考えてもゲロクソむずいけど、全オブジェクトをManuallyDropに包んで返して責任放棄するのかな……

**デフォルトの名無しさん** · 2024/11/10(日) 20:56:00.86

>>741
できねーもんはできねーんだから適切な道具を使うんだよ、笑うならそこの嘘吐き宣教師を笑うんだな

**デフォルトの名無しさん** · 2024/11/10(日) 21:08:26.24

>>742
プログラム本体終了後のメモリ解放のためにdropは必要ない
プログラム全体終了後のメモリリークが組み込みなどで困るケースが対象なのだからそれらメモリを返却するだけでよい

sbrkのあるOS環境ならsbrkでOSへ全メモリを返還できるのはその通りだが
それをしなくてもプログラム終了後にメモリリークは起きないので普通のアロケータでは行われていない
メモリリークが起きうる特殊なOSや組み込みならアロケータが借りてるメモリを全返却すればよい

**デフォルトの名無しさん** · 2024/11/10(日) 21:16:26.31

>>744
んでどっちのアロケータの話をしてるの？って

**デフォルトの名無しさん** · 2024/11/10(日) 21:22:25.58

>>745
普通の仮想メモリOS環境ならstaticでもBox::leakでもプログラム終了後にメモリリークは起きないから対策の必要がない
そうでない特殊なOSや組み込み環境ならばそれ用に用意するメモリアロケータをプログラム終了直前に呼び出して全メモリ返却させればメモリリークは起きない

**デフォルトの名無しさん** · 2024/11/10(日) 21:35:16.61

>>746
グローバルアロケータの話をしてんのか、カスタムアロケータの話をしてんのか、って聞いてんだよ

自分の頭の中の理屈をダンプするんじゃなく、言葉の定義をすり合わせる努力をしろ

**デフォルトの名無しさん** · 2024/11/10(日) 21:41:49.64

少なくともvalgrindとかperfmonみたいなやつは、プログラム終了時にヒープを辿って解放済みマークの無い場所を見つけたらリークって報告するんだし、一般的にはそれがリークだよ
プロセス終了時にメモリマップの割り当てが解除されるとか、どうでもええわ

**デフォルトの名無しさん** · 2024/11/10(日) 21:48:10.22

>>747
Rustでは#[global_allocator]指定でカスタムなグローバルアロケータを使える
プログラム終了後にメモリリークが起きうる組み込み環境なら対応した自作のアロケータを実装してそのように指定して用いる

**デフォルトの名無しさん** · 2024/11/10(日) 22:10:00.14

>>729
May I talk about the ownership reproduction in the formal community web page?

**デフォルトの名無しさん** · 2024/11/10(日) 22:15:02.72

> プログラム終了後にメモリリークが起きうる組み込み環境
組み込みやったことないから知らんけど、そんな環境があんの？

**デフォルトの名無しさん** · 2024/11/10(日) 22:27:44.25

https://github.com/rust-embedded/embedded-alloc

組み込みの典型的なコードってこのREADMEのサンプルコードみたいなんでいいのかね
プログラム(main)は終了しない
ヒープの「解放」処理も無い
合ってるよな？

自由に使える物理アドレス空間の一部を実行時アロケーションのために使用するってだけなら、使い終わりにやる「解放」の処理というのは何の話を言ってるんだ？って思ってたけど
そんなものはない、で合ってるのよな？

**デフォルトの名無しさん** · 2024/11/10(日) 22:31:44.37

>>750
search first

**デフォルトの名無しさん** · 2024/11/10(日) 22:33:46.00

>>751
そういう特殊な環境を出してるのは俺ではないからね
すべてを明示的に解放しなくても我々が普通に使っている仮想メモリ利用では問題ないよという話と
組み込みだとそんな仮定はできなくてメモリリークしていく可能性があるよという話の両方が出ているから
後者でも対応したメモリアロケータを用意すれば対応できるよと解決策を示した

**デフォルトの名無しさん** · 2024/11/10(日) 22:41:08.35

>>753
What do you mean? What I want to do is talking and having a discussion, not searching.

**デフォルトの名無しさん** · 2024/11/10(日) 22:48:01.15

>>754
> そういう特殊な環境を出してるのは俺ではないからね
あれ、そうだっけって思って辿ってみたら言い出してたの>>604だったわ
やっぱお前じゃねーか複おじ

プロセスにしろ組み込みのプログラムにしろ、OSだかシステムファームウェアだかの外部の管理者的存在が行儀の悪いやつのケツを拭いてくれてるだけのことを、
常識的のあるプログラマは「リークしていない」とは言わないんだよ

**デフォルトの名無しさん** · 2024/11/10(日) 23:04:28.91

プログラムの最後に行儀よくbrkやsbrkでOSへメモリを解放しているアロケーターを見たことないな
OSにとってはどうでもいいことだからそんな行儀よさは不要なのだろう
ましてやアロケーターの内部でフラグなどをオフにするだけのfree()はプログラムの最後にいらない
実行中に再利用できるようにするかどうかが本質だろうね

**デフォルトの名無しさん** · 2024/11/10(日) 23:16:52.46

えーではリークの定義に関して直接的反論はなしということで
以下はすべて誤りであったということでよろしいですね
対戦ありがとうございました

>>593「freeせずにプログラムが終了したり落ちたりしてもメモリリークは起きない」
>>604「freeを忘れてもあるいはfreeせぬまま異常終了となってもその仕組みによりメモリリークは起きない」
>>631「そしてfree()せずにプログラムが終了してもメモリリークは起きない」
>>744「sbrkのあるOS環境ならsbrkでOSへ全メモリを返還できるのはその通りだがそれをしなくてもプログラム終了後にメモリリークは起きない」
>>746「普通の仮想メモリOS環境ならstaticでもBox::leakでもプログラム終了後にメモリリークは起きない」
「そうでない特殊なOSや組み込み環境ならばそれ用に用意するメモリアロケータをプログラム終了直前に呼び出して全メモリ返却させればメモリリークは起きない」

**デフォルトの名無しさん** · 2024/11/10(日) 23:26:36.38

static mutは明らかにunsafeなわけだが
紙一重でunsafeとは言えないstatic変数のことを
警戒するかそれとも無駄な警備を極限まで捨てた合理主義の皇帝みたいに思うか
そういう対立はよくある

**デフォルトの名無しさん** · 2024/11/10(日) 23:33:02.28

プログラム終了後にメモリリークが起きるとすればOSが面倒をみてくれない環境だけだから
そういう環境では特殊な専用のメモリアロケータを用意するしかないだろうね
それならその自作のメモリアロケータをプログラム終了時に呼んで後始末させればメモリリークは防げる
Rustのstaticでヒープを持つ型を使っても最後まで使うメモリをBox::leak()で確保してもメモリリークは起こらないので安心していい

**デフォルトの名無しさん** · 2024/11/11(月) 00:17:42.59

Windows/Linux/macOSあたりなら
ファイルハンドルを閉じずにプログラム終了しても
OSが閉じてくれるから何の問題もない
的な主張？

**デフォルトの名無しさん** · 2024/11/11(月) 00:20:13.67

> プログラム終了後にメモリリークが起きるとすればOSが面倒をみてくれない環境
また実在しない環境の話し始めた

**デフォルトの名無しさん** · 2024/11/11(月) 00:28:54.94

間違いを認めなくても勝手にすりゃいいけど、そんなんじゃ誰とも意思疎通できないままだぞ
いくら長文を書き連ねても一緒

**デフォルトの名無しさん** · 2024/11/11(月) 00:56:28.26

2種類ある

OSレベルのclose (例えばC言語でのシステムコールを呼ぶclose()) ならばOSが処理してくれるので異常終了含めてプログラム終了時にcloseしていなくても構わない
ただし各言語ライブラリのバッファリングなど他の機能を持つcloseはプログラム終了までに自分でcloseしないとその機能が完遂しない

一方でメモリ解放の場合
OSレベルのメモリ解放 (例えばbrk/sbrk) ならばOSがそのプログラムの仮想メモリ全体を無効にするのでプログラム終了時に解放していなくても構わない
メモリアロケーターライブラリのレベルのメモリ解放 (例えばfree()) もOSにとっては全く無関係な話なのでプログラム終了時に解放していなくても構わない

**デフォルトの名無しさん** · 2024/11/11(月) 01:04:17.69

組み込みは詳しくないんだが今ってOSを使わない
組み込みでRustとか使うの？
Rustのターゲットって多分何らかのOSありきだよね

**デフォルトの名無しさん** · 2024/11/11(月) 01:08:33.73

>>765
語尾にオジを付けな

**デフォルトの名無しさん** · 2024/11/11(月) 01:10:52.04

マ板久々なので意味がわからないｗｗ

**デフォルトの名無しさん** · 2024/11/11(月) 01:11:20.28

webassemblyもなんか微妙な感じだしもったいない

**デフォルトの名無しさん** · 2024/11/11(月) 01:13:05.34

>>767
そっか、じゃあ過去のRust本スレを4年分復習してきな
あとここはム板だボケジジイ

**デフォルトの名無しさん** · 2024/11/11(月) 01:16:21.72

すまんのうｗｗ

**デフォルトの名無しさん** · 2024/11/11(月) 01:27:50.38

>>765
OS無しにも対応している
Rustの標準ライブラリstd::はOS前提の機能も入っていてOS無しだと機能しないものもある
Rustの必須な言語機能はcore::ライブラリに部分に分離してまとめてあるので
ベアメタルな組み込みなどではstd::を使わない#![no-std]を指定してcore::を使う
core::では数値型や配列やスライスに文字列(str)およびその複合型が使えるがヒープは対象外なのでVecやStringは標準機能としては使えないといった違いがある