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/10/28(月) 23:59:12.24

例えばよくあるこんな構造体を値とするHashMapがあったとして
struct Person { name: String, age: u32, }

このvalues()が返すのは&Person型なのでこう書く必要がある
for &Person { ref name, age } in hashmap.values() {
　println!("{name}: {age}");
}

ところが片方だけ参照にするとrefを記述しなくてもよくなる
for Person { name, age } in hashmap.values() {
ただしageも参照&u32になる

同様に片方だけ可変参照にするとmut refを記述しなくてもよくなる
for Person { name, age } in hashmap.values_mut() {

警備員[Lv.1][新芽] · 2024/10/29(火) 00:30:06.99

rustはOSやデバイスドライバなどを作る人が使うもので、ふつうに業務アプリなどを書くには敷居が高すぎるというか、習熟のためのコストが高すぎるというか、勿体無いというか
凡人には無用(無理)なのかな
学んでいて得るものは多いけど、そういった点でHaskellに似ていると思いました

**デフォルトの名無しさん** · 2024/10/29(火) 07:09:02.81

OSやデバイスドライバよりも上位の、例えばCLIアプリやバックエンドの開発にも役立つ言語だよ
Rustの利点は「低レイヤで必要なメモリ周りの管理ができる」ことだけでなくて、型による表現力の高さや、借用のなどのルールによるバグの防ぎやすさなどの強みもある
マルチスレッドだと、デッドロックは防げないけど、データレースなどの問題はコンパイル時の検査でほぼ防ぐことができる (個人的にはこれがすごく助かる)

業務アプリだと割に合わないというのは同意
Rustを理解してる人がチームに1人はいて、他の人に教えられる体制になってないと難しいと思う
習得時間をかけられなかったり、あまりレベルの高くない人もアサインするようなプロジェクトだとたぶん厳しい

簡単な言語ではないけど、Haskellほど難しくはないし、凡人には無理ってこともない (自分はRustを書いてるけど、自分だって凡人だし)
個人的に勉強しつつ、使えそうな機会があれば試しにRustで書いてみるというのはアリだと思う

**デフォルトの名無しさん** · 2024/10/29(火) 09:24:33.94

習熟が難しいのは確かだけど、どこでコストを考えるかだと思う。開発期間が増えてもバグ取りの工数は減るとか、サーバー負荷の削減で運営費が安くなるとか。今はAIでコード生成も出来るし、難しさが必ずしもデメリットとは思わない。

**デフォルトの名無しさん** · 2024/10/29(火) 10:26:21.77

Rust は清書用

**デフォルトの名無しさん** · 2024/10/29(火) 12:21:21.00

清書とかいう概念、実際やってるのみんな

**デフォルトの名無しさん** · 2024/10/29(火) 12:25:27.38

早くfirefoxを清書してほしい

**デフォルトの名無しさん** · 2024/10/29(火) 12:27:45.80

Servo落ちまくりなんだけど、Rustの品質が低いせい？

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

>>526
清書というから不思議なだけで、リファクタは常識かと。

Rustも、とりあえず動く段階からきっちり清書するまでシームレスにリファクタできればいいんだけどな。

**デフォルトの名無しさん** · 2024/10/29(火) 14:12:45.77

Rustを関数型扱いするやつは
Rustも関数型もまるで理解してない
だから誰も真面目には相手してくれない

**デフォルトの名無しさん** · 2024/10/29(火) 14:14:12.62

Rustほどリファクタリングに向いてない言語は無いな

**デフォルトの名無しさん** · 2024/10/29(火) 14:45:53.32

>>522
Haskell は言語自体は普段使いしやすいと思うが……。
しんどいのは副作用が存在しない (一般的に副作用とされるものが作用としてやりとりされる) という純粋関数型の部分で、このパラダイムの違いが外のシステムとの接続をやりづらくしてる。
いろんなライブラリやフレームワークの支えなしに業務システムを書くのは割に合わないし、辻褄合わせのラッパーライブラリを自分で書くのも面倒くさい。
(既にラッパーがある状況ならそんなにしんどくないけど。)
それと副作用のない世界でチューニングするのもしんどい。
必要なら仕方ないが他の言語ならしなくてよい苦労をする感じがするのがつらい。

Rust は C に ML 風の型システムを付けたくらいのごく普通のパラダイムなので、今まで業務アプリを作っていたくらいのスキルがある人にとってそんなにハードルは高いとは思わないな。
初心者が最初に手を付けるのはやめといたほうが良いとは思うが。

**デフォルトの名無しさん** · 2024/10/29(火) 15:33:28.84

>>528
コードの品質が低いんだろ
RefCellとかでちょっとしたメモリ競合リスクを検知してすぐに落ちるRustと
多少のメモリ競合リスクは無視して動き続けるC++の比較は品質というより好みの問題

**デフォルトの名無しさん** · 2024/10/29(火) 17:51:59.87

多くの人がOCaml選ばずRust選ぶ理由を知りたい
Rustより明らかに簡単

**デフォルトの名無しさん** · 2024/10/29(火) 18:39:05.10

>>532
>このパラダイムの違いが外のシステムとの接続をやりづらくしてる。
あんまり関係なくね？

パラダイムの違いはHaskell自体の習得には大きく関係あるけど
そこを超えてる人ならFFIでCのコードを呼ぶのは
C#やSwiftからCのコードを呼び出すのと大差ない

Rustの場合はFFIでもコンパイラがメモリ安全性を
保証できるように注意深くAPIを設計する必要があるから
FFI書くのはHaskellよりもややハードル高い

**デフォルトの名無しさん** · 2024/10/29(火) 20:13:57.88

>>517
refをレガシーとするのは間違っているため何年も前にその記述はBookから消されている

>>519
それは古いBookなので参考にしてはいけない
現在のBookにrefをレガシーとする記述はない

>>520
その公式リファレンスの記述が正しい
パターンが「その同型値・その参照・その可変参照」それぞれと束縛される時に
パターン内の変数に対してデフォルトの挙動が「移動・参照(ref)・可変参照(ref mut)」となる
これは人間工学的に自然な動作なので無意識に恩恵に授かれる

**デフォルトの名無しさん** · 2024/10/29(火) 20:19:56.52

Firefoxでもなぜか全然使われないrust言語

**デフォルトの名無しさん** · 2024/10/29(火) 21:06:17.79

Rustで多くの人が躓くのは借用やムーブのルールだと思う
ポピュラーな言語だと

fn foo(a: Vec<i32) {}
let a = Vec::default();
let b = a;
foo(b);

のような書き方でも単に参照が増えるだけだし、変数が消費されることもないから、
ここでコンパイルエラーになる時点で理解の壁がある
参照を学び始めたときも

fn bar(a: &mut Vec<i32>) {}
let mut a = Vec::default();
let mut b = &a; // これが正しい可変参照の書き方？
let c = &mut a; // それともこれ？
bar(c); // ここは bar(&mut c) じゃなくて良いの？

とかで迷う (自分はだいぶ時間がかかった)
この壁は言語のディープな部分に触れ始めたときじゃなくて、学び始めの頃にぶつかるから挫折しやすいように思う
この後もライフタイムなんかがあるし

OptionやResult, enumやパターンマッチは比較的理解しやすいし、利点も分かりやすい

**デフォルトの名無しさん** · 2024/10/29(火) 21:24:17.23

>>534
Rustに興味を持つきっかけが「表現力の強さ」ではなく「GC無しかつメモリ安全」という人が多いからじゃない？
自分の場合はC++で仕事をしてて、その次の選択肢となるとRustということで触り始めた
当時の自分は関数型言語というものを知らなかったし、Rust以外ではGoに行ってた可能性はあるけど、OCaml (あるいはHaskellやScalaやF#) は選択肢に無かったと思う

**デフォルトの名無しさん** · 2024/10/29(火) 21:24:34.03

>>538
それはどの言語でも同じ
4種類あり全て異なる

変数は不変　参照先も不変
【Rust】 let ptr: &i32 = ...
【C/C++】 const int* const ptr = ...

変数は可変　参照先は不変
【Rust】 let mut ptr: &i32 = ...
【C/C++】 const int* ptr = ...

変数は不変　参照先は可変
【Rust】 let ptr: &mut i32 = ...
【C/C++】 int* const ptr = ...

変数は可変　参照先も可変
【Rust】 let mut ptr: &mut i32 = ...
【C/C++】 int* ptr = ...

**デフォルトの名無しさん** · 2024/10/29(火) 21:29:47.89

循環参照が必要になるのは
設計者が頭悪しだからだよ

**デフォルトの名無しさん** · 2024/10/29(火) 21:46:14.89

>>536
英語版の最新のBookでレガシーという記述が消えてるのは確認したけど、refの記述自体も消えてた
大抵の場合は >>520 でうまく行くけど、場合によっては必要ということか
具体的にどういう場面で必要になるかがまだわかってないけど

**デフォルトの名無しさん** · 2024/10/29(火) 22:09:07.44

>>542
レガシーではないという理由で記述が削除されたのではなくて他にもレガシー化したパターンがある中でrefだけ特別にThe Bookに載せる必要はないという判断で削除されただけだよ

match ergonomics 2024のmotivationに書いてあるいくつかがrefの出番
https://github.com/rust-lang/rfcs/blob/master/text/3627-match-ergonomics-2024.md#motivation

**デフォルトの名無しさん** · 2024/10/29(火) 22:15:46.31

>>533
Rustで書けば品質の高いソフトウェアができる、と言い張る奴がいたら
Servoを見せれば論破できる

**デフォルトの名無しさん** · 2024/10/29(火) 22:39:28.16

>>543
サンクス

**デフォルトの名無しさん** · 2024/10/29(火) 22:53:06.91

Rustは関数型と主張しすぎないのが良かった。
gc無しでc++並みに速いから置き換え候補に入る。

scalaとかF#とか多少便利でもjavaやc#より遅いのでは乗り換えるメリットが少ない。

C++と比較すればrustは便利機能山盛りでメリットの方が目立つ。コードの書き方に違和感を持たせないまま関数型要素に慣らせるという戦略は上手く行ってると思う。

そこまで速度が必要なプロジェクトを組んだこと無い人には伝わりにくいのは仕方のない所。

**デフォルトの名無しさん** · 2024/10/30(水) 08:09:26.08

>>541
そういうことを言っているから、設計を動かさない枯れた技術向けの清書用言語になるんだよ。

**デフォルトの名無しさん** · 2024/10/30(水) 10:17:17.44

循環参照が必要になる話なんて誰もしてないよね？
>>541はなぜに唐突に循環参照の話をしたのか？

**デフォルトの名無しさん** · 2024/10/30(水) 14:04:48.00

循環参照が必要になる話は >>541 がしてるやん

**デフォルトの名無しさん** · 2024/10/30(水) 14:55:34.14

循環参照が必要だと思ったのは
書込者が頭悪しだからだよ

**デフォルトの名無しさん** · 2024/10/30(水) 18:39:18.26

>>531
「Rustはリファクタリングしやすいか？しにくいか？」議論＆投票
https://www.reddit.com/r/rust/comments/17jeezg/so_is_rust_easy_to_refactor_or_bad_to_refactor/
投票総数858件
643件 Rafactoring in Rust is Easy
215件 Refactoring in Rust is Hard
結果76%の人々がRustはリファクタリングしやすいとの結果に至った

**デフォルトの名無しさん** · 2024/10/30(水) 19:07:03.61

循環参照後から無くすって、ちょっとしたリファクタリングのレベルを超えているだろ
そのレベルの清書をマジでやるのか？
やらずにそのコードをそのままバグバグしい負債としてプロダクトに直接埋め込むんだろうどうせ

なら最初から循環参照なしで始めておこう

**デフォルトの名無しさん** · 2024/10/30(水) 19:41:43.03

循環参照の問題は意図せず起こってしまうことだと思うが
リンクリストとか特定のデータ構造はたいした問題じゃない
なんかポイントがずれてないか？

**デフォルトの名無しさん** · 2024/10/30(水) 20:10:19.86

>>522
でも速くて安全なんてキャッチフレーズ持ってるから、経営者が希望しそうな言語ではあるので将来的に現在のJavaみたいな立場の言語になりそうなのよね。＞Rust
（そういえば、当時のJavaも…ｹﾞﾌﾝｹﾞﾌﾝ）

**デフォルトの名無しさん** · 2024/10/30(水) 20:14:02.88

>>534
OCamlはRustよりもライブラリ揃っていなくてcargoのような簡易な環境もなくてコミュニティも小さくて実行速度も遅くて今から導入するメリットがなくてね

**デフォルトの名無しさん** · 2024/10/30(水) 20:23:49.98

>>554
クラウド時代となってCPUとメモリ両方の利用リソース量がコストに直結するようになったのも大きい
オンプレミスでもハード削減や電気代減少となるため速く動く言語への移行は進むだろう
以前は扱いやすく安全な速い言語がなかったところにRustが現れた

**デフォルトの名無しさん** · 2024/10/30(水) 20:23:51.06

implするときにtrait側の境界より厳しい境界を設定するとE0276エラーになるけど、緩くても特に何も言われないんだな
しかし別にそのトレイトメソッドを緩い条件で呼べる訳ではないという
なんかlintないんかねこれ

**デフォルトの名無しさん** · 2024/10/30(水) 20:39:06.44

>>556
ほんとそれ。
昔はマシン一台あたりの I/O (通信やデータベース) に対して CPU やメモリが余ってたから実行速度なんてそんなに気にしてなかった。
クラウド時代になって使ったリソース分で課金されるようになると削れる部分は削らざるをえなくなるよな。
なにせ金額は経営陣にも理解できる数値だから。

警備員[Lv.1][新] · 2024/10/30(水) 21:54:35.32

>>523
>>522 です
リプありがとうございました

その後の他のレスも併せて、もう少し粘って学習を続けてみようと思いました
大変励みになりました
ありがとうございました!!

**デフォルトの名無しさん** · 2024/10/30(水) 22:39:28.15

超大規模のシステムを運用してるんじゃなければ
Rustを使うことによるクラウド費用の削減効果なんて
人件費で軽く吹き飛んで負債になりまくりだろ

**デフォルトの名無しさん** · 2024/10/30(水) 23:07:53.41

そう思う人は遅い言語を使ってクラウド料金たくさん払えばよい

**デフォルトの名無しさん** · 2024/10/30(水) 23:47:20.95

CPU時間と実メモリ使用量で課金されるのはFaaS系だけって話前にもしたじゃん

**デフォルトの名無しさん** · 2024/10/30(水) 23:59:51.69

>>562
タイムシェアリングシステムではCPU時間で課金される

**デフォルトの名無しさん** · 2024/10/31(木) 03:34:36.66

自分の所は年間億単位のサーバー費用がかかるし開発も数年かかるんでrustに置き換えるのは十分元取れる。皆c++組めるんでrust教えるのも難しくない。

既に稼働中の部分を組み直す価値があるかは難しい所。Googleのように新機能の部分からrustで書いていくのがいいかな。

**デフォルトの名無しさん** · 2024/10/31(木) 12:55:27.39

541 が循環参照されてる

**デフォルトの名無しさん** · 2024/10/31(木) 14:32:08.16

Tokioチュートリアルをやっているんだけどさ
チュートリアルの本題とは違うものの、TcpListener::bind()やOSの仕組みがわからなくてすまんが教えてくれねえか
https://tokio.rs/tokio/tutorial/spawning
ここで出てきたんだけど、これってアドレスにリスナーをバインドしただけではなぜnetstat -aの結果には出てこないの？？？？

**デフォルトの名無しさん** · 2024/10/31(木) 14:46:55.34

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=220e62ef9b9cbfa9a15d1cdd2547de6b

ぜんぜんわからない
俺たちは雰囲気でライフタイムを書いている

**デフォルトの名無しさん** · 2024/10/31(木) 14:57:44.52

https://github.com/rust-lang/rust/issues/100728

あっこれかあ
fn(T) -> Uとかimpl Fn(T) -> Uはいいけどトレイトオブジェクトにすると全部非変になっちまうのか
ダルいなあこりゃ

**デフォルトの名無しさん** · 2024/10/31(木) 15:19:43.08

循環参照が無いなら
UAFは無くなるからだよ
馬鹿専用言語だと思った

**デフォルトの名無しさん** · 2024/10/31(木) 15:41:44.65

C言語だと、伝統的にはポインタを多用することで高速化が図られている。
その場合、循環参照はよく起きる。但し、その事に配慮してメモリーブロック(オブジェクト)を
destruct するようにしてあるので、特に問題ないし、馬鹿な設計でもない。
その方が速度効率が上がるためだから。

**デフォルトの名無しさん** · 2024/10/31(木) 17:20:18.37

参照カウントの場合の循環参照の話だから
C言語じじいは無理して入ってこなくていいよ

**デフォルトの名無しさん** · 2024/10/31(木) 18:04:25.22

>>571
参照化カウント方式のポインタで循環参照させる人は、そりゃ珍しいだろうよ。

**デフォルトの名無しさん** · 2024/10/31(木) 22:06:07.79

>>570
そのまとめてブロックでメモリ確保して一気に返す方法はRustや他の言語でも使われている普通の方法

**デフォルトの名無しさん** · 2024/10/31(木) 22:08:28.63

まとめて解放するため循環参照があってもまとめて解放される

**デフォルトの名無しさん** · 2024/10/31(木) 22:57:51.93

C言語で出来る事はRustでも出来るよという事がイマイチ浸透していない気がする。
カスタムのメモリアロケーターも作れるし、GC欲しければ自分で実装するか、人が作ったクレート使えばいいし。
循環参照の管理が難しいならそういうシステム最初に作るでしょ？

**デフォルトの名無しさん** · 2024/10/31(木) 23:23:13.46

GC自作とかいう大二病しぐさは大学生のうちに卒業しておけよ

**デフォルトの名無しさん** · 2024/10/31(木) 23:37:38.88

>>576
仕事で普通に使うぞ。
用途決まってれば別に特別でもない。

**デフォルトの名無しさん** · 2024/10/31(木) 23:50:49.71

まとめてメモリ解放の究極版として
常駐プログラムでないなど単発処理プログラム対象だと
Rustはleak()を使ってライフタイムの'static化つまりプログラム終了まで解放しない宣言することでプログラミングが簡易になるよ
Cで一部をfreeしないのと同じことだね

**デフォルトの名無しさん** · 2024/11/01(金) 00:52:09.22

C言語で出来ることの大部分は実はRustでは出来ない。

**デフォルトの名無しさん** · 2024/11/01(金) 00:52:09.90

C言語で出来ることの大部分は実はRustでは出来ない。

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

longjmpとか？

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

いや。ほとんどのデータ構造とアルゴリズムが、Rustでは効率良く使用不可能。

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

>>578
おいおい、Cでexitするときにfreeすべきか否かの論争はまだ決着がついてないぞ
勝手に決めつけるな

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

rustのgcって型に情報はみ出てんじゃん
ローカルでしか使えんし

**デフォルトの名無しさん** · 2024/11/01(金) 05:52:59.83

RustにGC無いよ

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

>>579
激遅でいいんならRustで出来るだろ

**デフォルトの名無しさん** · 2024/11/01(金) 09:12:07.99

libcクレート使えば、CとそっくりのRustプログラムできるでしょ

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

>>577
作りたいから作ってるだけだろ
仮に委託先がGC作成費用請求して来たらブチ切れて契約切るわ

**デフォルトの名無しさん** · 2024/11/01(金) 18:44:17.66

>>579
名前空間が無いからってマクロで識別子を生成するのはもう勘弁してください

**デフォルトの名無しさん** · 2024/11/01(金) 18:49:49.50

GCついてるRustが欲しい
rustのtraitシステムは好きだが静的メモリ安全性まではいらない

**デフォルトの名無しさん** · 2024/11/01(金) 19:00:04.84

>>590
ちょっと探したらGc機能を提供するクレートたくさんあったよ。
どれが良いのかは知らん。

**デフォルトの名無しさん** · 2024/11/01(金) 19:25:45.68

まともなGCライブラリなんかないよ
おとなしくRustらしいコードを書くか、Rustをやめるかだ

**デフォルトの名無しさん** · 2024/11/01(金) 21:49:04.02

>>583
freeやdeleteは不要
freeせずにプログラムが終了したり落ちたりしてもメモリリークは起きない

**デフォルトの名無しさん** · 2024/11/01(金) 22:49:51.10

>>592
だよな

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

>>593
メモリリークするかどうかはOSやアロケータ依存

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

>>593
お前、組込みソフトの開発したことないだろ

あ、俺もなかったわ

**デフォルトの名無しさん** · 2024/11/02(土) 00:41:46.39

>>593
メモリリークチェッカーが反応してしまうから、今時きちんと解放処理書くから
不要とかそういうのは前時代的だぞ

**デフォルトの名無しさん** · 2024/11/02(土) 01:36:59.35

Tと&TとRc<T>を区別できるのは静的型付けの成果なんだよな

LispがすべてをGCの対象にするのは型を宣言しないからだし
それに、副作用のある関数とない関数を「型」で区別できなかったから
すべてが純粋な関数だったら (動的型でも) 分かりやすいという話になった

**デフォルトの名無しさん** · 2024/11/02(土) 04:46:39.55

成果でもなんでもない
言語的にそうせざるをえないだけ
型で区別するのはいいことばかりじゃない

**デフォルトの名無しさん** · 2024/11/02(土) 07:03:08.78

技術の話をたまにしかしない人達に
技術は善いことばかりじゃないと説教するのは的外れすぎるだろ

**デフォルトの名無しさん** · 2024/11/02(土) 07:06:40.35

技術的な話をしてるから的外れ
型の弊害の経験ないからピンとこない

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

enumで解消

**デフォルトの名無しさん** · 2024/11/02(土) 14:38:12.14

とりあえず両極端を経験してみるのはじつは拙速で、巧遅でも清書でもない
どっちも弊害があると語る第三者が最も遅いのだ

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

>>595
それはむしろ逆
freeを完全にすることでメモリリークを防ぐことはできない
freeはアロケータが管理するメモリバッファへ返還する動作しかしない
malloc/free交互にするたびにそのバッファをゼロにするためOSやその他システムへバッファを返還する非効率をしない
アロケータが管理するバッファはfree後も常に一定量が残っている
つまりバッファを完全にシステム側に返還する責務をfreeは持たないしfreeで実現は無理だ
そこは各システムが別の機構として責務を持っている
普通のOSならプロセス終了でバッファ含めて使用メモリ全体を自動解放することになる
組み込みシステムでもそのプログラム終了時に少なくともバッファ部分を解放する仕組みを持たなければならない
freeを忘れてもあるいはfreeせぬまま異常終了となってもその仕組みによりメモリリークは起きない

**デフォルトの名無しさん** · 2024/11/03(日) 01:07:42.39

>>604
君が想定している仕組みや振る舞いが
あらゆるOSやアロケータに当てはまるわけではないんだよ

>>595に戻る

**デフォルトの名無しさん** · 2024/11/03(日) 08:19:11.87

まともなOSならfreeせずに終了しても問題が起こらないように作ってあるよ
そうしないと異常終了のようなケースでリークし続けることになるし
(古いものやマイナーなものも含めた全てのOSがそうだとは言い切れないけど)

その上でだけど、上記はOSの動作の問題であって、言語のルールとしては「mallocしたら対になるfreeを呼ぶこと」だろうから、自分の好みとしてはfreeをちゃんと呼ぶよう作りたい派
「OSが解放するから問題ない」というのは「プログラマが責任をサボっても問題は起こらない」という感じがしてて、行儀の良いコードでないように感じる

**デフォルトの名無しさん** · 2024/11/03(日) 08:27:05.14

mallocしたら対になるfreeを呼ばずに終了するのはマナー違反
目上のOSに対して失礼に当たる

**デフォルトの名無しさん** · 2024/11/03(日) 08:32:32.56

こういうやつに限って問題が起きると「想定外でした」と恥ずかしげもなく言うんだよな

**デフォルトの名無しさん** · 2024/11/03(日) 08:32:33.64

メモリリークが問題になるのは、むしろ終了させずに長期間稼働させ続ける場面でのことだと思うが…。
特に鯖とか医療機器・自動車組み込みなど、経済・人命に影響が大きい分野。

**デフォルトの名無しさん** · 2024/11/03(日) 08:37:43.84

>>609
そういう分野では、そもそも動的にメモリ確保しない

**デフォルトの名無しさん** · 2024/11/03(日) 09:04:30.66

動的確保をしないものもあればするものもある
自分の知ってる範囲が世の中の全てだと勘違いしないことだな

**デフォルトの名無しさん** · 2024/11/03(日) 09:25:18.11

医療機器や自動車ほど重要なものではないけど、自分の仕事だと組込みでも動的確保を使うよ
Windows EmbeddedやUbuntuようなOSが入ってるし、それなりのリソースがある環境での話だけど
「大きなバッファはプログラムの最初に1度だけ確保する」ことはするけど、それ以降のヒープ確保をしないとか、static領域のみを使うとかまではしてない
(Rustスレでいうのもなんだけど現状はC++)

一般化できる話かは分からないけど、例えばカメラを使う機器かつ複数種類のハードウェアを扱うプログラムなら動的確保は必要じゃない？
想定するカメラ画像のうち最も大きいサイズに合わせたメモリを静的確保する作りでも良いと思うけど、プログラム起動後にハードウェアに問い合わせて、それを元に必要分のバッファを確保する作りも多いと思う

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

>>612
確実にメモリ不足が起こらないこと保証できるのそれ？
まあ動くっしょ？ダメなら再起動で、みたいな感じ？
品質に対する意識すごいね

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

mallocが駄目ならsbrkを使えば良いじゃない。by マリー

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

> malloc/free交互にするたびにそのバッファをゼロにするためOSやその他システムへバッファを返還する非効率をしない

なんやこの悪文は

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

>>609-610
手術中にGC走り出したら困るもんなー

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

>>615
chatGPTに聴いて造らせたような文章だな

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

ChatGPTはそんな変な文を作らない。

**デフォルトの名無しさん** · 2024/11/03(日) 16:50:47.89

MS-DOSですら、free忘れようが何しようが、
プロセス終了時にちゃんとOSがプロセスが確保した
メモリーを解放してたよ。

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

なんせ、MS-DOSのように「意味的には」ページングして無い場合には、
メモリー解放はOS目線で見れば簡単と言えば簡単だからね。
for ( プロセスが確保していたメモリーブロックを全て巡る ) {
　(そのメモリーを解放);
}
みたいなロジックであって。
WindowsやLinuxのようなOSでは、ページングや色々なこと
してるから複雑だけど、それでもOSは頑張って解放するよ。

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

素人質問で大変恐縮ですが、CPU/GPUのファームウェアをrustで書くことは可能？