Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

Mozilla発のRust言語のスレ

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

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

前スレ
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/03/09(月) 12:37:33.41

なんかトレイトの命名でなるべく名詞ではなく動詞を使う(WriterではなくWrite、ReaderではなくRead)みたいなのがオフィシャルの文書で有ったような気がするんだけど見つからない
そんな指針って無かったっけ？

**デフォルトの名無しさん** · 2020/03/09(月) 12:52:18.51

>>141
オフィシャルにはapi-guidelinesだと思うけど特になさそう。
このissueで議論されてるけど特に結論はでてないし。
https://github.com/rust-lang/api-guidelines/issues/28

**デフォルトの名無しさん** · 2020/03/09(月) 13:05:24.07

>>141
話し合いしている様子は見つけた。
https://github.com/rust-lang/api-guidelines/issues/28
どちらを優先するという話ではなく、使い分けがあるっぽい。

**デフォルトの名無しさん** · 2020/03/09(月) 21:11:10.09

一年くらい前に挫折して最近また勉強し始めたんだけど参照周りの仕様変わった？
https://doc.rust-jp.rs/rust-by-example-ja/scope/borrow/freeze.html
これとかエラーにならないし

**デフォルトの名無しさん** · 2020/03/09(月) 21:47:20.13

>>144
昔は一度借用するとスコープアウトするまで借りっぱなしだったけど、今は使われなくなった時点で返すようになってる。
non lexical lifetimeというやつ。
英語版だとちゃんとエラーになるように修正されてるね。
https://doc.rust-lang.org/rust-by-example/scope/borrow/freeze.html

**デフォルトの名無しさん** · 2020/03/09(月) 22:32:56.28

>>138
試しに触ってみた感じだけど、戻り値をVecに格納しようとすると怒られるよね。
で、よく見ると引数のtextはtokenizer自身と全く関係の無い寿命であって良いのに、tokenizerとtextの寿命が同じであるってシグネチャで言ってるから何かマズそう
多分もっと理解できる人も居るだろうけど、selfとtextの寿命を無関係にしたら動くってなんとなく分かる
pub fn tokenize_str<'s, 'a>(&'s mut self, mut text: &'a str) -> Vec<&'a str> {
ってやったら動くよ。省略ルールで
pub fn tokenize_str<'a>(&mut self, mut text: &'a str) -> Vec<&'a str> {
と同義。

俺の頭の中の理解じゃプルリク送れるほど明快に説明できないが、適当にローカルに落とすかgithubでforkして使っても良い

**デフォルトの名無しさん** · 2020/03/09(月) 22:35:30.43

>>145
non lexical lifetimeっていうのね。Rust日本語情報が少ないので助かるわ。thx

**デフォルトの名無しさん** · 2020/03/09(月) 23:22:38.75

>>147
しかしそもそも借用によるフリーズって意味なくなってるから
そのページ全体書き直した方がいい感じ。
フリーズするならシャドーイングによるmut外しかな。

**デフォルトの名無しさん** · 2020/03/10(火) 15:02:44.20

>>138
Linderaってのがkuromoji-rsの後継らしいからそっち使えば？
https://qiita.com/mosuka/items/0fdaaf91f5530d427dc7
https://github.com/lindera-morphology/lindera

該当箇所のライフタイムは修正されてるのでtokenizerのインスタンスをループで使っても問題ない
https://docs.rs/lindera/0.3.4/src/lindera/tokenizer.rs.html#163-173

ただドキュメントは整備されてないし
ライブラリ自身のテストも通らない状態になってるから
本格的に使うなら自分でメンテするくらいの覚悟が必要かもしれん

**デフォルトの名無しさん** · 2020/03/10(火) 19:42:21.39

>>149
ありがとうございます、後継なんてあったんですね。
最近出来たみたいですがそれほどメンテされてないみたいですしこの先不安なので素直にPython使うことにします。
日本関係依存のライブラリはRustユーザー少ないので確立されたものがないのが辛いですね...

**デフォルトの名無しさん** · 2020/03/10(火) 19:58:15.03

rustも字句解析も相当知ってなきゃそれ使うの無理だろ。。

**デフォルトの名無しさん** · 2020/03/11(水) 18:46:16.77

vecのinto_iter呼んだらconsumeするって
fn into_iter(self) -> イテレータ {self}
こういうふうになってるってこと？
よく分かってない質問ですみません。

**デフォルトの名無しさん** · 2020/03/11(水) 18:56:11.75

あ、consumeじゃないわこの場合
moveって言いたかった

**デフォルトの名無しさん** · 2020/03/11(水) 19:43:34.97

自己解決？

https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-IntoIterator
impl<T> IntoIterator for Vec<T>

こうなってるからそのまま self を返してるに違いない
よーわからんけどなんとなく納得

**デフォルトの名無しさん** · 2020/03/11(水) 19:46:02.45

よく分からないのに納得してしまうのはよくない

**デフォルトの名無しさん** · 2020/03/11(水) 20:15:44.69

>>154
ソースで理解したいんならここ。

https://doc.rust-lang.org/src/alloc/vec.rs.html#1934-1952

Vecのポインタを使ってIntoIterを構築して、元のVecはforgetでメモリ管理対象から外してる。

**デフォルトの名無しさん** · 2020/03/11(水) 20:40:35.00

>>155 おっしゃるとおり
>>156 おおおお！！！
想像とは違ってunsafeの中であれこれしてた！
impl<T> IntoIterator for Vec<T> {
type Item = T;
type IntoIter = IntoIter<T>;
fn into_iter(mut self) -> IntoIter<T> {
unsafe {
let begin = self.as_mut_ptr();
let end = if mem::size_of::<T>() == 0 {
arith_offset(begin as *const i8, self.len() as isize) as *const T
} else {
begin.add(self.len()) as *const T
};
let cap = self.buf.capacity();
mem::forget(self);
IntoIter {
buf: NonNull::new_unchecked(begin),
phantom: PhantomData,
cap,
ptr: begin,
end,
}
}
}
}
いやあ勉強になります

**デフォルトの名無しさん** · 2020/03/11(水) 22:03:42.73

fn into_iter(mut self) -> IntoIter<T>

このmut selfのmutの使い方について
意味は理解してるんだけど公式で解説してる箇所ある？

**デフォルトの名無しさん** · 2020/03/11(水) 22:44:26.55

なんでextern crate crate_name;ってuse crate_name;に統合されたの？

**デフォルトの名無しさん** · 2020/03/11(水) 23:04:39.68

>>159
RFCに書いてある理由はこの辺り
https://github.com/withoutboats/rfcs/blob/modules/0000-modules/motivation.md#underlying-problems

**デフォルトの名無しさん** · 2020/03/12(木) 06:53:02.39

serde, reqwestとかを使ってるだけの小さいツールなのに
targetディレクトリ以下がいつの間にか2GB以上喰ってて驚いた
無駄遣いしすぎだろ

**デフォルトの名無しさん** · 2020/03/12(木) 09:00:30.33

ぜろこすとおーばーへっど(笑）

**デフォルトの名無しさん** · 2020/03/12(木) 09:20:01.92

>>158
公式系のやつを一通り検索したけどなさそうだね。
確かに頻出パターンではないし、mut selfが必要になる頃には
それくらい分かるだろってことなんだろうか。

**デフォルトの名無しさん** · 2020/03/13(金) 01:08:14.21

容量くうのってインクリメンタルコンパイルのせいかしら？

**デフォルトの名無しさん** · 2020/03/13(金) 16:12:49.45

cargo run --bin bin_a　で bin_a から a にバイナリ名をrenameできる方法ない？
オプションとかで

**デフォルトの名無しさん** · 2020/03/13(金) 17:20:18.20

>>165
標準ではないと思うから以下の三択
1. コマンドを自作する
2. プラグインを探す
3. Cargo.tomlの編集で我慢する

**デフォルトの名無しさん** · 2020/03/13(金) 17:48:43.18

>>164
インクリメンタルコンパイルの内部構造知らないけど、仕組み的に一個前の状態しかもたないから関係なさそう

**デフォルトの名無しさん** · 2020/03/13(金) 20:50:49.12

お前らのtargetディレクトリは何GBあるんだ？

**デフォルトの名無しさん** · 2020/03/13(金) 21:21:22.50

duとかdustでどのcrateが容量食ってるのか
きちんと確認したほうがいい

**デフォルトの名無しさん** · 2020/03/13(金) 22:52:16.46

dustで一番ディスク喰ってるプロジェクトを調べてみたよ

target/debug/depsの下に
lib(serde|derive_more|syn|reqwest|chrono_tz)-xxxxxxx.(so|rlib)
が各ライブラリごとに3つずつぐらいあって、それぞれ21～38MBぐらいあった
その他、依存ライブラリの依存ライブラリと思われる *.rlib ファイルが260個
これだけで 1.4GB

target/debug/build の下が400MBぐらい
target/debug/incremental の下は100MBもない

同様のファイルがtarget/releaseにもあって合わせると 2.3GB

**デフォルトの名無しさん** · 2020/03/14(土) 01:08:40.11

エコシステムが充実してるのはいいが、
ぞろぞろと依存を引き連れて落ちてくるのはしんどいな。

**デフォルトの名無しさん** · 2020/03/14(土) 09:57:16.83

う、うん…

**デフォルトの名無しさん** · 2020/03/14(土) 13:30:22.96

Rustに限らず誰が書いたかも知らないまま誰がチェックしたかも知らないまま何がダウンロードされるかも知らないままインストールするのが当たり前になっちゃってるよな
ソースが公開されてるとは言えこれじゃいかんよなぁとは思いつつ楽だからまぁいっかな…って感じだわ(´・ω・`)

**デフォルトの名無しさん** · 2020/03/14(土) 13:52:26.42

わからないまま終わる。そんなのは嫌だ(´・ω・｀)

**デフォルトの名無しさん** · 2020/03/14(土) 13:58:57.65

実際なんかの言語で問題起こしていたような

**デフォルトの名無しさん** · 2020/03/14(土) 14:53:10.70

node.js

**デフォルトの名無しさん** · 2020/03/14(土) 15:14:32.21

誰が書いたかも知らないまま誰がチェックしたかも知らないまま何がインストールされるかも知らないままOSをインストールするのが当たり前になっちゃってるよな

**デフォルトの名無しさん** · 2020/03/15(日) 11:00:03.22

公式アプリストアしか使えないとか真逆の動きだろ
何指してるんだ？

**デフォルトの名無しさん** · 2020/03/15(日) 12:03:48.31

実際のところ、そんなのいちいち精査してられんだろう。

**デフォルトの名無しさん** · 2020/03/16(月) 23:59:03.20

arrayvecとsmallvecってどっち使えばいいの？

**デフォルトの名無しさん** · 2020/03/17(火) 04:52:34.09

好きな方。

**デフォルトの名無しさん** · 2020/03/17(火) 10:23:26.40

arrayvecとsmallvecよく見てないけど同じぐらい人気だからどっちでもよさそう
それよりもロガー周りが何選んだらいいか分からん(env_logger抜きで)
ファイル保存したいからlog4rsかfernかslogで迷ってる
ライブラリ選びはホントにRustの欠点だよな

**デフォルトの名無しさん** · 2020/03/17(火) 11:06:35.06

まあねぇ。部品は連携してこそのものだから、
どっちでもいいものでもどちらかには決まってた方がありがたいってのはあるわな。
自由の強さと統率の強さは両立できないのでしゃーない。

**デフォルトの名無しさん** · 2020/03/17(火) 11:30:02.19

確かに選びにくいんだけど、型が強いのとコンパイルエラーが見やすいから、移行コストが結構低い気はしている。
なので最近はあまり気にせず適当に選ぶことにしてるな。

**デフォルトの名無しさん** · 2020/03/17(火) 13:15:29.64

スタック上に確保するStringライブラリってあるの？

**デフォルトの名無しさん** · 2020/03/17(火) 17:38:45.49

rust-avって今どういう状況なん？
だいぶ前にlibavの人たちがMozillaから数万ドル支援を受けて始めたとかニュースになってたけどgithub見ても実質的にはほぼ何も進んでないようなコミットばっかだしlibavすらほぼ放置みたいな感じだし
非公開の場所で着々と進んでてそのうち公開されるんやろか

**デフォルトの名無しさん** · 2020/03/18(水) 05:43:30.43

C++の負の仕様引きずってるなってRustの特徴とかある？

**デフォルトの名無しさん** · 2020/03/18(水) 09:41:00.53

C++の負の仕様って何？

**デフォルトの名無しさん** · 2020/03/18(水) 21:47:04.33

winapi 0.3.8 の環境にて、CoCreateInstanceを行いたいのですが、
REFIIDの指定部分をどのように書けばよいか教えてくださいませ

**デフォルトの名無しさん** · 2020/03/19(木) 00:16:54.84

なんでassert_neはあるけどassert_notはないの？

**デフォルトの名無しさん** · 2020/03/19(木) 01:43:10.57

notと!が続いて少し紛らわしい
なくてもそんな困らない
必要なら作ればいい
とかかな

macro_rules! assert_not {
($cond:expr) => { assert!(!$cond) };
($cond:expr,) => { assert!(!$cond) };
($cond:expr, $($arg:tt)+) => { assert!(!$cond, $($arg)*) };
}

**デフォルトの名無しさん** · 2020/03/19(木) 15:19:47.59

assert!(!false);
の方が紛らわしくないか？
assert_not!は関数名の方に!あるから見間違えないしスッキリするし直感的な気がする
それにneが内部的に反転してるだけならnotあったほうがいいな

**デフォルトの名無しさん** · 2020/03/20(金) 07:03:37.86

usize同士の差の絶対値を求めるのがすごくだるいんですけどなんかいい方法ないすか

**デフォルトの名無しさん** · 2020/03/20(金) 07:38:59.81

if x > y { x - y } else { y - x }
じゃ駄目かい

**デフォルトの名無しさん** · 2020/03/20(金) 08:14:22.57

やっぱそうするしか？

**デフォルトの名無しさん** · 2020/03/20(金) 16:54:06.07

そういう関数を作っておけばええやん。

**デフォルトの名無しさん** · 2020/03/21(土) 19:08:12.84

let mut v = vec![1,2];
std::mem::swap(v[1], v[0]);
assert!(v == vec![2,1]);
こうしたいんですけど、どうすればいいですか？

**デフォルトの名無しさん** · 2020/03/21(土) 19:19:05.58

Vec::swap使え->
Vec::swapは中でunsafe使ってるじゃないですか結局unsafe使わなきゃろくなこと出来ないんですねRustってクソですね

ってやりたい荒らしだろ？
氏ねばいいと思うよ

**デフォルトの名無しさん** · 2020/03/21(土) 19:32:13.45

標準ライブラリ内でunsafe使うのと
自前でunsafe使わされるのとは雲泥の差があると思うんだがｗ

**デフォルトの名無しさん** · 2020/03/21(土) 20:27:19.94

ヤクザかな？

**デフォルトの名無しさん** · 2020/03/21(土) 20:38:04.64

ほら、万が一の荒らしじゃないケース用に答えも同時に提示してあげたのにそっちには見向きもしないでしょ
そりゃそうだよね、実際はやりたいことの質問じゃなくてRustをディスるための質問なんだもんね

つかそもそも本当に質問のことがやりたいなら提示したコードをコンパイルしようとしてるはずだよね
そしたら親切なコンパイラが&mutで借用しろって教えてくれてるよね
そしたらそれに従ったら今度は親切なコンパイラが同時に2つmutな借用は作れないって教えてくれてるよね
じゃあどうしたら良いですか？ってなるのが普通だよね

それがないってことは質問を装っていながらコンパイルすらしてないってことだからね
荒らすんなら荒らすでもうちょっと頭使おうね☆

**デフォルトの名無しさん** · 2020/03/22(日) 13:10:01.70

Rustにも、次のような「言語定義された smart pointer」があり、
~ : 一回だけ(unique) 参照する smart pointer。
@ : 複数回参照できる smart pointerで、GC を使っている。
drop なるものが、C/C++ の free()やdeleteの機能を持つ。
という認識で正しいのでしょうか。

**デフォルトの名無しさん** · 2020/03/22(日) 14:01:25.52

>>202
参照カウンタを1引くようなDeref や、C/C++の単項演算子の方の「*」と
全く同様な「参照はずし演算子」の「*」もあるようですね。
また、~ や @ よりは少し高レベルになった smart pointer として、
Box<T> が、参照カウンタ方式の smart pointer として Rc<T> が、
さらに、動的(?)になった smart pointer としてRef<T>やRefMut<T>
があるようです。
凄く複雑です。

**デフォルトの名無しさん** · 2020/03/22(日) 14:28:20.92

参照型の変数 r への代入は、普段は、
r = 1;
などでよいようですが、なぜか、*r と書かなければなら無い事があるようです。
また、&i32の変数rとi32の変数aを比較する場合比較する場合、
前者には *r を付けないといけないようです。
難しいです。

**デフォルトの名無しさん** · 2020/03/22(日) 15:43:22.86

6年以上前に削除された仕様の良し悪しを語りたいのか？

**デフォルトの名無しさん** · 2020/03/22(日) 15:57:03.70

rustの未来教えて

**デフォルトの名無しさん** · 2020/03/22(日) 16:08:02.82

>>205
詳しくお願いします。

**デフォルトの名無しさん** · 2020/03/22(日) 16:50:19.83

>>207 いやbook読んでよ。もし@とか~についての記述があったら逆に教えて欲しいくらいだ

**デフォルトの名無しさん** · 2020/03/22(日) 17:28:44.77

>>204
&と*は常に逆の関係にあるようです。
The opposite of referencing by using & is dereferencing, which is accomplished with the dereference operator, *.

vがvecへの参照型の場合でも
v.push(5);
と書けてしまうのは、実体vとポインタ pV に対して
v.push(5);
pV->push(5);
と区別していたC++と違っているために個人的に混乱していただけのようです。

もう一つは、参照ではなく、
let a = 5;
let a = a + 1;
のように shadowing を行う例が個人的に混乱の原因になっていたようです。

参照型 &T の場合には、
let r : &mut TYPE = &a;
のようにした後は、
*r = xxx;
のように、原則的に * を付けて参照を一段階戻す必要があるようです。
*をつけなくていいのは、メンバ関数呼び出しの、
r.func();
のような例の場合だけで、もしかすると、
(*r).func();
としてもコンパイルが通るかもしれません。

**デフォルトの名無しさん** · 2020/03/22(日) 17:30:53.65

>>208
https://pcwalton.github.io/2013/03/18/an-overview-of-memory-management-in-rust.html
Rust の 2種のスマートポインター、^ と @ に詳しいです。

「book」と言えば、詳しく学ぶには、まさに
https://doc.rust-lang.org/book/index.html
が初心者には分かり易いようです。
この本のことでしょうか？

**デフォルトの名無しさん** · 2020/03/22(日) 17:52:06.65

7年も前の情報を無条件に信じられるピュアさが俺にも欲しいよ

**デフォルトの名無しさん** · 2020/03/22(日) 17:52:35.28

>>210
Rustの1.0リリースは2015年なので
それより古い資料は「昔そういう検討がなされたことがある」程度の意味しかない。
この5年の間に変わった仕様も結構あるし。

**デフォルトの名無しさん** · 2020/03/22(日) 18:32:23.24

初心者なんだけど
もし１つの変数（所有権）にマルチスレッドで書き込みをしようと思ったら、
Rustの借用のルールだと不可能ですか？
複数のイミュータブルな参照を作る事になりますが、できないんですよね？

**デフォルトの名無しさん** · 2020/03/22(日) 18:40:28.26

あまちがえました
訂正：
複数のミュータブルな参照を作る事になります

**デフォルトの名無しさん** · 2020/03/22(日) 18:53:15.15

>>213
同時じゃなければ可能なので
他のマルチスレッドプログラミングと同じく排他制御をすればいい

**デフォルトの名無しさん** · 2020/03/22(日) 19:02:35.81

実行時にデータ競合系の問題が生じない代わりに
コーディング時に借用チェッカーとの戦いをするという感じになるんですかね

**デフォルトの名無しさん** · 2020/03/22(日) 19:17:35.15

>>210 そのbookだよ。オフィシャルのドキュメントを読まずにどうして深入りできようか
１点だけ。rustではobj.method()とするとメソッドの引数の型(&とか&mutとか)に合うようにobjに*とか&とか付ける仕様になってる
メソッド呼ぶ時のobjに対してこっちが*とか&とか付ける必要は特に無い

**デフォルトの名無しさん** · 2020/03/23(月) 01:35:58.42

>>217
bookの話、了解しました。
後半、「メソッドの引数の型」とは、た第一引数 thisのことでしょうか。

**デフォルトの名無しさん** · 2020/03/23(月) 01:39:22.78

所有権、借用、ライフタイムについて勉強してみた。
でも他の言語でも排他制御とか非同期処理用クラスで非同期処理に対応できるわけで、
結局どれくらい御利益があるのか分からなかった。

**デフォルトの名無しさん** · 2020/03/23(月) 02:29:29.77

Rustの変数束縛、所有権、借用などで自動化されるのは、
「スタック変数」のポインタが、ブロックの外や関数の外に不用意に出ない
事だけで、Heapから確保されたオブジェクトの自動解放は、
参照カウンタや Garbage Collection を用いずに静的解析のみで行うことは出来ない、
という認識で正しいのでしょうか？？

**デフォルトの名無しさん** · 2020/03/23(月) 02:39:09.37

>>220
例えば、Cだと、
int *func()
{
　int a;
　return &a;
}
としても警告は出る可能性はあってもコンパイルエラーにはなりませんが、
Rustでは同等のことはできないようになっていますね。
でも、Heapから確保したオブジェクトは、それを参照している変数の個数は
動的に変わります。というのは、Heapとは解放のタイミングを後に遅らせる
ための仕組みな分けですから。
オブジェクトを参照している変数の個数は静的に決まらないと言うことは、
参照カウンタやGarbageCollectionのような動的な検査の仕組みが全く無ければ
解放できないはずですね。

もし静的に解放タイミングを決められる可能性があるとすれば、参照の個数に上限を
設けることによってです。簡単な例ではそのオブジェクトを参照する変数が1つしか
ないなら、その変数にnullや別の値が代入されたり、その変数が削除されるタイミング
だけを静的に調べれば自動解放できるはずです。
しかし、2つ以上になった場合、参照カウンタ無しで静的に削除タイミングを決定するのは
かなり難しくなります。

**デフォルトの名無しさん** · 2020/03/23(月) 03:10:34.91

私が読んだ説明記事では所有権やライフタイムはローカル変数かつシングルスレッドの例しかなかったんですが、
それだとRustがどう非同期処理に強いのかイメージできませんでした。
グローバル変数やマルチスレッドでライフタイム等の概念が活用されている例ないですか？

**デフォルトの名無しさん** · 2020/03/23(月) 06:41:08.54

Rust では所有権が移るから、資源を共有しないからだろ

資源を共有すると、アクセスするタイミングで、バグってしまう。
A を更新 → B を更新 → Aを読み取り

間に、Bが入ったことで、AはBの値を読み取ってしまったけど、
その場ではエラーにならず、かなり後になって、データが何かおかしいと誰かが気づくかも知れない。
気づかないかも知れない

だから、あちこちで排他制御をせざるを得ない。
そうすると、デッドロック・タイムアウトも考えないといけない

**デフォルトの名無しさん** · 2020/03/23(月) 09:52:06.45

資源を共有しないんじゃなくて、共有していい資源かどうかを型（SendとSync）で区別している。
なので排他制御が必要な箇所に入ってなかったらコンパイルエラーにできる。
だからデッドロックなんかは起きるけど、レーシングは起きないって感じ。
ライフタイムはそれほど関係ない。

**デフォルトの名無しさん** · 2020/03/23(月) 12:20:19.11

マルチスレッドの話は置いておいて、そもそも Rustでは、Heapから確保したオブジェクトの解放は自動化されてますか？

**223** · 2020/03/23(月) 12:54:01.89

>>223
修正

>A を更新 → B を更新 → Aを読み取り
スレッドA が共有資源を更新 → B が更新 → Aが読み取り

**デフォルトの名無しさん** · 2020/03/23(月) 13:43:29.57

基本的なことが理解出来てない人はまずThe Bookを読もう

次からテンプレに書いといたほうが良さそう

**デフォルトの名無しさん** · 2020/03/23(月) 15:20:59.29

読んでそこまでたどりつくのは大変過ぎますので、どなたか分かる方が >>225 に答えていただければ幸いです。

**デフォルトの名無しさん** · 2020/03/23(月) 15:33:10.24

>>225
自動で解放される。なぜされるのかが気になるならいろいろ想像してないでthe bookを読んだ方がいいと思う。

**デフォルトの名無しさん** · 2020/03/23(月) 15:33:45.55

贅沢は敵です。

**デフォルトの名無しさん** · 2020/03/23(月) 15:38:31.12

Rc<T> は参照カウンタ方式で自動解放されますが、循環参照があった場合には自動解放されず、メモリーリークするそうです。
つまり、RustはHeapのメモリーを完全自動では解放できないのです。
C#やJavaは遅いですが、循環参照がある場合でも、GarbageCollectionにより完全自動で解放されます。

**デフォルトの名無しさん** · 2020/03/23(月) 15:39:33.51

つまり、「Rustは、GarbageCollectionがなくてもメモリ解放が自動化されている」
というのは嘘です。

**デフォルトの名無しさん** · 2020/03/23(月) 15:40:41.93

>>228
その部分だけの説明は出来ない。そこにたどり着くまでの説明は関連してるから。
体系立てて説明している文書が公式にあるのにそれより上手い説明が出来るわけないだろ。

**デフォルトの名無しさん** · 2020/03/23(月) 15:41:06.82

>>231
https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust

[Q] Is it possible to cause a memory leak in Rust?

Is there any way of causing a memory leak in Rust? I know that even in garbage-collected
languages like JavaScript there are edge-cases where memory will be leaked, are
there any such cases in Rust?

[A1]

Yes, leaking memory in Rust is as easy as calling the std::mem::forget function.

You can also leak memory if you create a cycle of shared references:

A cycle between Rc pointers will never be deallocated. For this reason, Weak is used to break cycles.
For example, a tree could have strong Rc pointers from parent nodes to children, and Weak pointers
from children back to their parents.

**デフォルトの名無しさん** · 2020/03/23(月) 15:45:50.08

>>233
結論的に言えば、Heapから確保されたオブジェクトのメモリの解放は自動化されてません。

**デフォルトの名無しさん** · 2020/03/23(月) 15:49:21.93

なんだ。真面目に聞いてるのかと思ったのに。
まぁご自由にどうぞ。

**デフォルトの名無しさん** · 2020/03/23(月) 16:15:56.91

>>236
実際に自動化されていませんよね。

**デフォルトの名無しさん** · 2020/03/23(月) 16:28:50.38

真面目に回答した相手が荒らしだった時って｢何だよ荒らしかよ｣みたいな反応より｢クッソ抜けるwww｣からの｢すいません誤爆しました｣みたいなレスで｢真面目に回答したわけじゃないぞ、シコりながら適当に回答したんだぞ｣的な雰囲気を出してったほうが良さそうじゃない？

**デフォルトの名無しさん** · 2020/03/23(月) 16:58:35.58

Rc<T> だけを使って循環リストを作った場合、循環参照が生じます。
その場合、その循環リスト全体が誰からも参照されなくなって、つまり、不要に
なっても「循環参照問題」が起きるために自動解放できないのです。

C#やJavaでは、この循環参照問題を解決することを主目的として、
遅さを犠牲に Garbage Collection を使っています。
これは「動的解析」に分類されます。

一方、Rustの場合は静的解析だけで済まそうとしていますが、結局、循環参照問題のために
完全自動化は出来ず、解放べきメモリが解放されずに残ってしまうという現象がおきえます。
これを防ぐには、人間側が循環リストの最後と最初を結ぶためには、weak pointer を使う
などの注意深いプログラミングをすることで防ぐしかありません。
つまり、人間の注意深さでメモリーリークを防いでいるだけです。

**デフォルトの名無しさん** · 2020/03/23(月) 17:09:05.71

都合の悪いことには誰も答えません。