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/04(月) 23:29:15.46

政治起因による制約さえ無くなれば経済が偉大になるという謎理論があるからな

**デフォルトの名無しさん** · 2024/11/05(火) 22:33:43.60

>>652
Rustなら色々な安全性を全て保ったまま扱えるよ
所有者と所有権を消滅させることと引き換えに&'static mut Tを得ることも安全に行われている

**デフォルトの名無しさん** · 2024/11/05(火) 23:42:46.08

&'static mut Tに何か代入したらどうなるの
代入前の値にdropが定義されてたら呼び出される？
それは実質的にfreeしてるのと同じなのでは

**デフォルトの名無しさん** · 2024/11/06(水) 00:29:29.78

>>655
デストラクタはその型の値に対して行われるものであって
一般的にはヒープメモリとは関係がない
たまたまその型(の一部)がヒープメモリを所有すれば当然解放される

一方で&'static mut Tの元はBox<T>そして&'static mut [T]の元はVec<T>
つまり解放されないのはBoxやVecという入れ物でありTの話ではない

**デフォルトの名無しさん** · 2024/11/06(水) 07:25:52.71

構造体メンバーに!Copyを入れれば制約が生じる
Box<T>が!Copyだとしても&'static TはCopyだから制約がなくなった
ように見えるが、ヒープとか解放とかいうクソどうでもいい条件が増えてるんだよな

**デフォルトの名無しさん** · 2024/11/06(水) 08:04:15.27

&Tにスタック領域かヒープ領域かスタティック領域かの区別はなく意識することさえ必要ない
唯一の制約はライフタイムであり
staticでない&'a Tは所有者である'a Tより延命できない制約がある
一方&'static Tはプログラム終了時まで永遠に生きるため制約がない

**デフォルトの名無しさん** · 2024/11/06(水) 23:12:54.20

同時に意識しろとはいわないが
少しずつでも森羅万象を意識しないと客観的にならない

**デフォルトの名無しさん** · 2024/11/07(木) 22:29:40.21

>森羅万象

いわばまさに、だーらば

**デフォルトの名無しさん** · 2024/11/07(木) 22:47:47.58

static変数へ入れてしまう場合もプログラムの最後までヒープ解放しないよね
例えば以下は正規表現わざわざ使うまでもない簡単な例だけど
ヒープ領域を確保して内部に持つRegexを何度も作り直すムダを避けるためにstaticに持つよくあるパターンとか
それを解放するきっかけは最後までやって来ないよね

fn yyyymmdd(s: &str) -> Option<(u32, u32, u32)> {
const YYYYMMDD: &str = r"(\d\d\d\d)/(\d\d)/(\d\d)";
static RE: LazyLock<Regex> = LazyLock::new(|| Regex::new(YYYYMMDD).unwrap());

if let Some((_, [year, month, day])) = RE.captures(s).map(|caps| caps.extract()) {
let year = year.parse().ok()?;
let month = month.parse().ok()?;
let day = day.parse().ok()?;
Some((year, month, day))
} else {
None
}
}

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

RustにJAVA厨が流れ着いてるのか

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

}
else {

**デフォルトの名無しさん** · 2024/11/08(金) 10:14:50.92

汚ジコード乙

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

毎回初期化を避けるためにstatic←JAVA脳
ローカル変数やauto変数にいちいちstatic描かなくても一回しか初期化されない←関数脳

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

>>665
JavaだけでなくCでもRustでもどの言語でも同じだろ

**デフォルトの名無しさん** · 2024/11/08(金) 15:26:29.46

regex literalのある言語を知らないとか原始人かよw

**デフォルトの名無しさん** · 2024/11/08(金) 17:32:32.77

>>667
regex literalのある言語でもパターンが変数により変わる場合は別途生成になる
その場合に正規表現からオートマトンへのコンパイル結果をキャッシュする責務はプログラマー
それを何らかのオブジェクトに入れて毎回持ち回るのか避けてstatic変数などに入れてしまうかの話ではないか

**デフォルトの名無しさん** · 2024/11/08(金) 18:37:15.71

>>668
マジでregex literal知らんのだな
raw string literalとは違うのだよ！

**デフォルトの名無しさん** · 2024/11/08(金) 19:37:52.69

今確信したけどここまでの流れを見て断言するけど
Rustが主流の言語になることはないわな

**デフォルトの名無しさん** · 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)は終了しない
ヒープの「解放」処理も無い
合ってるよな？

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