[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 11/01 06:23 / Filesize : 300 KB / Number-of Response : 1022
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part11



1 名前:デフォルトの名無しさん mailto:sage [2021/06/17(木) 00:24:12.56 ID:NvYoNP9C.net]
公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

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

日本語の情報
https://rust-jp.rs/

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

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

956 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 10:36:03.26 ID:ZbJNhF7k.net]
>>937
Rustでは弱参照を使うデメリットありますか?

957 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 10:50:20.08 ID:6chE64yn.net]
>>938
生存期間を意識した非対称なコーディングをしなければならないこと、だね
親子関係の循環参照でどちらを弱参照にすべきかはケースバイケースであり、>>934が思っているほど単純な話ではない
別にRustを批判してるわけじゃないが、GC言語から見ればそれ自体がデメリットなんだよ

958 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 11:23:41.21 ID:XXiZs56E.net]
これまでRust書いている時にトレーシングGCが欲しくなったことはありますか?
それはどのようなプログラムを書いている時ですか?

959 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 11:40:32.83 ID:ueMbvV/8.net]
>>934
その通り。
ツリーでなくてもある地点から一方向のみの有向グラフになるような強参照の時
そのある地点が解放されれば残りも解放される

960 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 13:03:00.15 ID:mUiDivSN.net]
PythonやSwiftの自動参照カウント方式はGCとは呼ばない派がいるんだね

Rustの場合は弱参照を使うかどうかに関わらず
生存期間を常に意識してコーディングする必要がある
どちらを弱参照にすべきかは所有権を考えれば明白

961 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 13:26:39.80 ID:gvYYeNdp.net]
C++ スレでスマートポインタが GC かどうかという話題が出たことあるわ。
そこで現れた GC の定義としては大まかに

@ 十分に信頼してメモリ管理をまかせることが出来る能力がある
A メモリ管理を意識することなく利用できる

のいずれか (または両方) が上げられていて、
その上で信頼性の程度、意識するというのがどの程度のことを言うのかで
様々な線引きがある感じだった。

たとえば@については参照カウンタだと循環を解決できないが、
それはエッジケースでしかなくてたいした問題じゃないと考えるか
そうでないかは人によるが、いずれにしてもまかせるに足る能力で
考えるという考え方。

Aについてはメモリ管理を自動化する能力ではなく見せ方の問題だとする派閥。
スマートポインタは管理方法も管理内容も決まっていて
プログラマがそれを利用するという明示が含まれるので GC ではないという考え方もあるし、
管理の開始こそ明示的な宣言ではあるものの
直接的な管理は隠されているので GC だという主張もある。
どちらに線を引くかは異論があるにせよ、プログラマの側からどう「見えるか」という
抽象度の問題とする考え方。

962 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 13:46:29.34 ID:VyqoTEns.net]
>>943
違うよ
GCの定義は明白で
「ガベージが生じて溜まっていってそれらをまとめてコレクションすること」
だからRustで例えばノードツリーのトップが何らか任意の方法でドロップとなった時
連鎖的にツリー全体が次々とRcの強参照カウント0となりツリー全体が解放されるのはGCではない
即座に消えてガベージは溜まって行ってないため

963 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 14:21:58.28 ID:cpmwRu6w.net]
>>944
明白か?
そんな定義は無いと思うが。
GCの起源はLISP由来だと思うけど、その時の実装は参照カウントでは?

964 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 14:28:20.76 ID:cpmwRu6w.net]
あ、すまん。LISPはマークアンドスイープで、その後に参照カウントが発明されてるわ。



965 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 14:53:47.52 ID:HA74v0pt.net]
>>945
参照カウント方式か否かは焦点ではなくて、ゴミがたまっていってまとめて処理することをgarbage collectionと呼ぶ。
RustのRc利用はゴミがたまっていかないのでGCと呼ばれていない。

966 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 15:46:33.74 ID:a+6ajIdY.net]
>>944
「溜まっていってそれらをまとめて」というのは間違いだな。
wikipediaの記載にある
「不要になった(メモリ)領域を自動的に解放する機能」
というのが正しい。
ポイントは「不要と判断」して「解放」というところ。溜まる必要もまとめて解放する必要も無い。

967 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 16:12:57.05 ID:gvYYeNdp.net]
個人的には GC であるかそうでないかという議論はそれほど意味が感じられない。
GC という切り口からメモリ管理を見ることが出来るという切り口だと考えてる。
極論すれば C の自動変数も「スコープを抜けたら不要 (ということにする) と判断」して「解放」してるので
GC の一種と言えば一種とも見れるし、しかし参照 (ポインタ) が残ってるかもしれないし
それを経由してアクセスしたらワヤになるので (GC としては) 出来が良くねぇなぁってだけのこと。

968 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 16:20:23.00 ID:I6cNZKXd.net]
>>948
Garbage Collectionなのだからゴミ集め
ゴミが溜まったら拾い集めること
RustのRc利用だとゴミは溜まらないので「RustにはGCはない」と世間でも言われている通り

969 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 16:26:13.36 ID:7qCp8Y9u.net]
即時解放はGCじゃないと思うわ
スマポも即時解放なのでGCじゃない派

970 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 16:27:26.84 ID:7qCp8Y9u.net]
逆に言うと解放のタイミングが基本的に制御できない、つまりIDisposableみたいなのが必要になるならGCという認識

971 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 16:40:48.46 ID:gvYYeNdp.net]
ほとんどの場合に参照が 0 になるより前にゴミになっているが
ゴミであることがわかるのがカウントが 0 になったときなんだ。
カウントが 0 になったときをゴミになったときだと定義づけるのは因果が逆転している。

972 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 16:59:28.87 ID:2x1SlAHu.net]
それは言葉遊びだな

973 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 17:08:30.56 ID:vyeTxMra.net]
>>953
参照0より前にゴミになった状態を把握する一貫した方法を示せれば貴方が勝てる可能性がある。
示せなければあなたの負け。

974 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 17:39:51.03 ID:gvYYeNdp.net]
>>955
小学生かwww 勝負してるわけじゃないだろ。
俺は GC とそうでないものを分ける意味があまりないという立場だ。

「即時」とそうでないものが GC かどうかを分ける境界だという主張に対して
実際には即時に近いものもあればそうでないものも中間もあってそのどこに
線を引けるのかは自明ではなく程度問題だと考えている。



975 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 18:01:17.23 ID:xSD6Fm/R.net]
>>948 その基準だとCの自動変数解放もGCになるね。

976 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 18:04:49.13 ID:fiEjE9/t.net]
中間なんてあるか?

977 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 18:20:07.16 ID:ksTslrDC.net]
>>957
さすがにスタックフレームの移動は含まないんじゃないか

978 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 18:29:19.97 ID:OwFrNtUI.net]
>>959
関数を終える時点でゴミとなるので解放
だからRcと同じ即時解放タイプとなる

私は即時解放するならばGCでないと考える
だからRcやスタック変数はGCではない
つまりRustにはGCはないとの定説通り

979 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 18:59:47.21 ID:a+6ajIdY.net]
>>957
システムが不要と判断して開放しているならそうだが、実際には違う。
まだ必要(ポインタとかで参照されている)としている領域でもスコープから抜ければ削除されるから、「不要になった領域を削除する機能」とは言えない。

980 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 19:39:34.81 ID:cpmwRu6w.net]
>>947
まとめて処理しなくてもcollectionだろ。
お前がフィギュアを集めてるとして、欲しいものを溜めて一気に買ってるのか?
定期的に収拾する事自体がcollectionじゃん。

981 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 19:41:33.72 ID:XXiZs56E.net]
まとめて処理しないとGCではないというのなら
GCのパラメーター変更して毎命令処理の度にGCが走るようにしたらGCではなくなるということ?

982 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 19:43:45.53 ID:XXiZs56E.net]
与太話はさておきただ単にGCと言うだけでは伝わりにくいから
トレーシングGCとかリファレンスカウント(GC)とか言った方がよいのでは

983 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 19:48:18.23 ID:u6qceEgo.net]
>>964
そこは論点ではない
リファレンスカウントでも即時解放していればGCではない
ガベージが貯まってから解放処理をしていればGC

984 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 20:08:33.56 ID:/6K8Gxc1.net]
所有権を設定して、ブロックスコープを抜けた所有権のある変数はすべて開放とかよく考えたよね



985 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 20:15:04.57 ID:2vdDGXAS.net]
リファレンスカウントは、c++のスマートポインタみたいな循環参照でリークするのと、pythonみたいに循環参照してるゴミを後から回収するのがあるから、後者はリファレンスカウント(GC)と呼ぶべきということでしょ?
前者はGCではない

986 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 21:23:06.49 ID:uNBAsbKx.net]
全く関係ない話するけど、
Rustは、可変参照型の変数を右辺に書いて、moveのソース側にすることは
可能?
それとも、moveのソース側は、普通の所有権がある可変変数でないとダメ?

987 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 21:41:50.19 ID:mUiDivSN.net]
>>968
moveのソース側って?

ownedの引数にmutable borrowは渡せない
fn foo(mut i: i32){…}
let x = 42;
foo(&mut x); // error

988 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 21:49:03.56 ID:uNBAsbKx.net]
>>969
let x = 構造体名{初期化メンバの列};
let y = x;
と書いた場合、x の内容がy に moveされるけど、
let mut x = 構造体名{初期化メンバの列};
let z = &mut x;
let y = *z;
とすることは可能?

989 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 22:02:36.97 ID:mUiDivSN.net]
>>970
なるほどそういうことか
構造体がCopyなら可、Copyじゃなければ不可

990 名前:デフォルトの名無しさん [2021/08/23(月) 23:33:12.95 ID:7m4C54nZ.net]
GCという言葉がそこまで細かく使わなきゃいけない言葉になってることに意味がない気がする

991 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 23:50:41.85 ID:uNBAsbKx.net]
>>971
Copyって、Cloneじゃなくて POD 的な場合に単純コピーされるというやつの事?

992 名前:デフォルトの名無しさん mailto:sage [2021/08/23(月) 23:57:23.53 ID:z0XKxUto.net]
>>973
便乗質問
ムーブで関数に渡してもコピーできない型はcall by valueではなくポインタが渡るのですか?

993 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 00:18:52.33 ID:MkJE9y3A.net]
>>973
Copy はトレイトだがそれ自体はただのマーカーでしかなく特に実装しなければならないメソッドはない。
Copy が実装された型はムーブの文脈でコピーになる (所有権を奪わない)。
https://doc.rust-lang.org/std/marker/trait.Copy.html

clone

994 名前: (必要な文脈では) 自動で呼ぶってだけ。
複製の仕方は Clone の実装のほうに従う。
[]
[ここ壊れてます]



995 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 00:33:59.68 ID:MkJE9y3A.net]
>>974
ムーブの実態はビット単位のコピー。
ムーブ元は「今後絶対に使われない」という静的な強力な保証があるから
有効なオブジェクトはひとつだけなんだ。
ビットパターンの複製は作られるよ。

コピー (クローン) という用語は Rust 的にはあくまでも静的な所有権管理と紐付いていて
機械語レベルでデータが複製されるかどうかとは関係がない。

996 名前:デフォルトの名無しさん [2021/08/24(火) 08:40:18.86 ID:wPEcGzhk.net]
>>930
お互い個人の感想なので強くは言いませんが、公式に上がっている例を見ていただければ、たった数十行で
リーク構造を作れることは分かってもらえると思います。
あなたが言う通りにRc<T>の特性を知って使いこなしているのであれば別ですが、初心者が全て知っている事は
稀、レアというよりあり得ません。またRc<T>をWeak<T>に直すのが大変という話ではありませんよ。
データ構造上のリング構造や、ツリー上に出来てしまった循環参照を前提に(リークはするが)動いている依存
コードが多量にあるプログラムを影響を与えないように直すのが難しいという話です。これはRustではなくても
他の循環参照を明示的に破棄しないプログラムを書いてしまえば同じ事ですが。
Rustは大変に高パフォーマンスで、明示的な制御が効きますが>>895で言っているのは技術レベルが違う二者で
苦労する人が一定数発生する事でしょう。言語とはほぼ何の関係ありませんが

997 名前:デフォルトの名無しさん [2021/08/24(火) 08:45:48.38 ID:wPEcGzhk.net]
まあ将来的にはコンパイラーがより賢く・早くなれば循環参照で増え続けるリークに対してコンパイルエラーにも
出来ると思うので、今は未だ、リークする可能性があろうとRustが良い言語だという認識は変わらない。
他の言語でも当然リークチェックは出来るが、GCを前提とするならコンパイルエラーが出ても、なぜエラーなのか
理解しずらいかもしれない。

998 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 08:48:26.31 ID:GKvpHEIf.net]
行数の問題ではなく、Rcを使って独自のデータ構造を作るスキルがあるのに循環参照だけ知らない初心者、というのはレアということでは
まぁそれはそれとして直すのが難しいケースがあるのは同意

999 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 09:23:53.65 ID:OGtUhL4y.net]
・Rustで循環参照が起きるにはRc利用が必須
・Rc利用者は循環参照の存在もそれを避けるWeakの存在も知っている
・したがってRustでメモリリークを生じさせる者はレアケース

・Weak(弱参照)を適切に上手く用いて循環参照を避けるのが大変な場合もあるが全ての言語で共通の問題でありRustの問題点ではない

1000 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 12:45:30.39 ID:PednkAUi.net]
>>971
なるほど。Rustのオブジェクト型であるところの struct はデフォルトでは
Copy trait は実装されないので、>>970 の後半のように借用を介して
moveのsource側にすることは禁止されているということなのね。

1001 名前:デフォルトの名無しさん [2021/08/24(火) 15:09:04.48 ID:KCG/N/Sb.net]
rustってどうやって二重開放のリスク防いでるの?全然ピンとこない

1002 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 15:50:18.44 ID:tu56M8w7.net]
ownershipが1つしかない状態を維持しつつownershipが0になったら(確実に)解放する感じ

ownershipはどこかの変数が直接的or間接的に保有してて
同じリソースに複数のownershipが発生しないように
代入とか関数の受け渡しでmoveしたりborrowしたりする

少し逸れるけど解放処理を必要としないデータはCopy可能な場合が多い
ownershipは「所有権」て訳されるけど意味的には「解放権」とか「解放責任」に近いかも

1003 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 16:38:09.46 ID:Cd1Pd2YU.net]
>>977
公式の見解を個人の感想と一緒にするなよ

1004 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 17:46:18.00 ID:uCQTu6bl.net]
Rustで循環参照作るの簡単とか言ってるやつは100%エアプだからほっといてやれ
他言語での経験をあたかもRustで経験したかのように語りたかったんだろう



1005 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 18:15:27.00 ID:otdRB8MX.net]
>>985
メモリリークの原因になるかどうかを別にすれば、循環参照自体は普通に簡単に生じるだろう

1006 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 18:45:16.53 ID:tu56M8w7.net]
unsafeでポインタ使えば簡単だろうけどライフタイムのある参照の循環は大変そう
'a > 'bと 'b > 'aを両立は不可能に見えるけど何か抜け道あるのかな

1007 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 18:55:37.63 ID:SZKxopPy.net]
循環参照どころか連結リストも荷が重い

1008 名前:デフォルトの名無しさん [2021/08/24(火) 19:43:21.83 ID:KCG/N/Sb.net]
>>983
なるほどサンクス
リージョン理論に線形論理を上手く組み合わせて、cycloneとかの欠点を克服したrustってすげーなあ
とはいってもそもそも二重開放してエラーになるというのがピンとこない
free(a);
free(a);
は二重解放しているように見えて合法だろ?
一度目のfreeでaにNULLが代入されて、二度目のfreeでは引数がNULLの場合はそのままreturnって処理されるんだから、理論上は何度free使ってもエラーにならないじゃないか

1009 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 19:58:14.02 ID:Mn5s1DvN.net]
何の話? C?

1010 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 20:39:00.27 ID:972JwtmU.net]
>>980
>Rustで循環参照が起きるにはRc利用が必須
RcだけじゃなくRcとInterior Mutabilityが必須
(どちらか片方はmutableじゃないと循環させられないので)

>Weak(弱参照)を適切に上手く用いて循環参照を避けるのが大変な場合もあるが
Rustの場合は循環参照で意図通り動くコードを書くのに比べれば
弱参照に変更するのはすごく簡単

循環参照を修正してる例
https://github.com/DataDog/glommio/commit/677fe1dfbaf911245fbc5c3eef75532d08d784bf
https://github.com/KWARC/rust-libxml/commit/bd4b120b90b2568ca6d5bfaa368a200573b87d09

1011 名前:デフォルトの名無しさん [2021/08/24(火) 20:58:14.10 ID:joymTvc2.net]
すまんが、複数のファイルにソースを分割する練習教材みたいなものがあったら教えてくれんか?

1012 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 22:56:02.07 ID:972JwtmU.net]
次スレ
https://mevius.5ch.net/test/read.cgi/tech/1629813327/

1013 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 23:03:55.04 ID:PednkAUi.net]
>>992
「book」にもモジュールの章がある。

1014 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 23:31:00.93 ID:OsSSnb/8.net]
>>987
RcとRefCell使えば数行



1015 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 23:45:46.97 ID:MkJE9y3A.net]
循環によって現れるメモリリークは Rust が提供する「メモリ安全」を損なわないと定義されている。
Rust は循環参照を防がないし、メモリリークに対処するのはプログラマの責任。

1016 名前:デフォルトの名無しさん mailto:sage [2021/08/25(水) 00:57:06.67 ID:3XgQgETH.net]
>>992
もう見てるかもだが
www.sheshbabu.com/posts/rust-module-system/

1017 名前:デフォルトの名無しさん [2021/08/25(水) 01:28:54.33 ID:6n+Di1sM.net]
>>990
c

1018 名前:デフォルトの名無しさん [2021/08/25(水) 01:29:12.12 ID:6n+Di1sM.net]
うんこ

1019 名前:デフォルトの名無しさん [2021/08/25(水) 01:29:33.60 ID:6n+Di1sM.net]
1000ならここにいるやつら全員失職

1020 名前:1001 [Over 1000 Thread.net]
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 69日 1時間 5分 21秒

1021 名前:過去ログ ★ [[過去ログ]]
■ このスレッドは過去ログ倉庫に格納されています






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<300KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef