Rust part11

**デフォルトの名無しさん** · 2021/06/17(木) 00:24:12.56

公式
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/

**デフォルトの名無しさん** · 2021/08/22(日) 08:43:57.27

>>880
それはブロックスコープといって多くの言語が備えておりプログラミングの基礎です
まさかNimには存在しないのですか？

**デフォルトの名無しさん** · 2021/08/22(日) 08:57:00.52

rustスレでnim nim言ってる奴荒らしだろ

**デフォルトの名無しさん** · 2021/08/22(日) 09:00:12.62

>>862

マクロのシンタックスを別で覚える必要がない
Rust のマクロは構文が全く変わってしまいます。
そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。
公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに
由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で
「なんじゃそりゃ」と言う言葉しか出ません。

Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための
障壁の低さは比べ物になりません。

**デフォルトの名無しさん** · 2021/08/22(日) 09:19:59.80

次世代言語22 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1629590343/

**デフォルトの名無しさん** · 2021/08/22(日) 09:21:24.81

nim
https://mevius.5ch.net/test/read.cgi/tech/1519896738/

**デフォルトの名無しさん** · 2021/08/22(日) 09:49:19.77

実際rustって色々リンクするから、最小バイナリでかいよな
でも、それで困ったことってあるか？
俺はない

**デフォルトの名無しさん** · 2021/08/22(日) 09:53:06.17

>>891
それはリンクする状況にするからであってRustのせいではない
例えばRustを使って組み込みやWASM等でもバイナリでかいと思ってないよね

**デフォルトの名無しさん** · 2021/08/22(日) 10:05:41.39

Rustは他に比べれば最小のバイナリでしょ、コンパイラ/リンカーが長い年数を掛けて最適化されたCより大きいが。
一番不満なのが公式はビルドが速いというがそんなに早くない事だけ。それ以外は従来のC/C++（C++17/20/23
なんかを除く)より圧倒的に安全だし、明示的であるからこそタイプ量が多い。
Nimに比べて大きいというのはRustのコンパイラがまだCを吐き出してた頃から最適化されていないから、Nimと
いうかGCCやClangに比べ、ほんの少し大きくなる。リンクするものが大きければバイナリが大きくなるのは
当然でGoなんかはまさにそれでしょ、goroutineを共有ライブラリに押し込めることは出来ないから

**デフォルトの名無しさん** · 2021/08/22(日) 10:06:16.71

>>892
まあ、ユーザコード自体のサイズがでかいわけじゃないのは同意

**デフォルトの名無しさん** · 2021/08/22(日) 10:17:01.78

もう１つ不満がある事は、Rustならメモリーリークしないと言う奴がいる事、公式も明言してる通り
グローバルの循環参照を作成してしまえば簡単にリークするのに、意識高い系のコード書かないやつが
メモリーリークしないんだと他の言語も触ったことの無い初心者に力説する事。盛大にリークしてて
正常に動いてるプログラムを直すのは大変・・・
ま、これは言語のせいじゃないけどね、他は凄い良く出来てる、Linuxカーネルに採用されるような
他の言語（第３の言語）は当分出てこないだろうと思うほど

**デフォルトの名無しさん** · 2021/08/22(日) 10:35:44.30

Rustのメモリ安全性は、メモリリークしない、ではないからな。

**デフォルトの名無しさん** · 2021/08/22(日) 10:40:22.74

>>895
Rustは弱参照があるから強参照の循環参照を作らずに済みます　
よってまとまなプログラミングをしていればメモリーリークは起きません

**デフォルトの名無しさん** · 2021/08/22(日) 10:42:20.85

>>895
javaでも同じことを言う奴がいる
「GCが頻発する。GC壊れてる」
壊れてるのはお前のコードだ

**ハノン** ◆QZaw55cn4c · 2021/08/22(日) 10:52:46.02

>>867
構ってあげるから別スレ建ててください
C へのトランスレータであることは魅力的ですよね

**デフォルトの名無しさん** · 2021/08/22(日) 10:54:43.87

>>895は分かってる人だろう
ちゃんと読んでるか？

**デフォルトの名無しさん** · 2021/08/22(日) 11:49:45.30

ビット全探索する関数作ったヽ(´ー｀)ノ

fn bit_search<T: Copy>(vec: &Vec<T>) -> Vec<Vec<T>> {
　let mut tmp_vec: Vec<Vec<T>> = Vec::new();

　for i in 0..(1 << vec.len()) {
　　let mut slist = (0..vec.len())
　　　.filter(|it| i & (1 << it) != 0)
　　　.map(|it| vec[it]).collect();
　　tmp_vec.push(slist);
　}
　return tmp_vec;
}

使い方
let vec0 = bit_search(&(0..5).collect());
など

**デフォルトの名無しさん** · 2021/08/22(日) 12:16:08.62

>>862

Rust の良いところ
さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。
Rust にも良いところはあります。

fn <- 短い！

proc <- 長い！

これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。

**デフォルトの名無しさん** · 2021/08/22(日) 12:22:55.13

>>902
どうでもいいだろ
それが0文字の言語も8文字の言語も併用しているが長さで困ったことはない
タイプ数を気にするのは愚か者だけだ

**デフォルトの名無しさん** · 2021/08/22(日) 12:30:03.84

この仕組みを教えて下さい
もしかして2bit＋1byte＝2bytesってこと？

> > Option<Option<T>> has layout [0..1][0..1]<u8> , i.e., be of size 3
>
> False. Thanks to @eddyb’s work, the compiler will collapse the discriminant of the first option into the second. Thus, mem::size_of::<Option<Option<u8>>>() == 2.

**デフォルトの名無しさん** · 2021/08/22(日) 12:37:43.49

>>895
他の言語に比べれば循環参照を作るハードルはかなり高いでしょ

現実的な用途でborrow checkerに引っかからないような循環参照を作って
リーク以外は機能的に問題ないコードを書くのは初心者には難しいと思う

**デフォルトの名無しさん** · 2021/08/22(日) 12:55:40.93

さすがにマルチポストは荒らし以外の何物でもないな

**デフォルトの名無しさん** · 2021/08/22(日) 13:03:58.26

>>904
the compiler will collapse the discriminant of the first option into the second.
って言ってるから
Option<Option<u8>>はOption<u8>に変換されるってことじゃない？

**デフォルトの名無しさん** · 2021/08/22(日) 13:18:58.50

>>554-555
あたりが物になるのはいつかなぁ
組み込みだとLLVM縛りは結構きつい

**デフォルトの名無しさん** · 2021/08/22(日) 13:46:33.46

>>904
Optionで9回包んでもsizeは2のままだったのでそういうわけではなさそう
None, Some(_), Some(Some(_)) の3バリアントがあるのと同じようなレイアウトになる模様
↓はOption<Option<Option<u8>>>の例

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=31c195fa7390041e3a2d7ce9ff1417f2

**デフォルトの名無しさん** · 2021/08/22(日) 14:20:53.63

909のコードを借りて確かめてみたら
<Option<Option<Option<u8>>>>(&Some(Some(None)));
と<Option<u8>>(&Some(None))が
<Option<Option<Option<u8>>>>(&Some(Some(Some(0))));
と<Option<u8>>(&Some(0))が同じ結果になったよ
1byte目が00の場合None、00以外の場合Some
<Option<Option<Option<u8>>>>(&Some(None))みたいに
OptionとSomeのレイヤの数が違うと1byte目の結果が違うみたい
1byte目でどのレイヤのSome/Noneか区別してるのかな

**デフォルトの名無しさん** · 2021/08/22(日) 14:35:04.66

[0..=3]<u8>になってるね
nightlyで#[rustc_layout(…)]を使うと確認できる

#![feature(rustc_attrs)]
#[rustc_layout(abi, size, debug)]
type Foo = Option<Option<Option<u8>>>;

**デフォルトの名無しさん** · 2021/08/22(日) 15:31:41.81

Itertoolsが便利すぎて今までの自分が可愛そうすぎる(´･ω･`)

**デフォルトの名無しさん** · 2021/08/22(日) 17:33:05.93

>>862

技術書典に出会っていなかったら俺はNimをさわってないと思う

背景
俺たち「そろそろ技術書典に参戦するか」
俺たち「何書く？」
俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」
ワイ「(マイナーの定義はさておき)Nimでオナシャス」
ワイ「(アドカレあるし、記事まとめておくかぁ...)」

Nimとは？
Nim はアンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、
コンパイル言語という特徴を持つプログラミング言語です。

アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々
な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。
それがNimプロジェクトの始まりで、2005年頃のようでした。

当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から
2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。

**デフォルトの名無しさん** · 2021/08/22(日) 18:20:04.94

結局rustもC++を遥かに超える型地獄なんだな

**デフォルトの名無しさん** · 2021/08/22(日) 18:47:16.61

こんだけ型がっちがちに固められた言語触っちゃったら他の言語に戻れない

PythonとかPythonとか

**デフォルトの名無しさん** · 2021/08/22(日) 19:10:19.80

型地獄って何？

**デフォルトの名無しさん** · 2021/08/22(日) 19:11:44.78

二度と出られぬかーたーじーごーくーーー

**デフォルトの名無しさん** · 2021/08/22(日) 19:15:51.20

実行時にバグるよりコンパイルエラーでコンパイル出来ない方が遥かに優れていると思ってるけど, そう思わないと型が辛くなるだろうなぁ

**デフォルトの名無しさん** · 2021/08/22(日) 19:27:07.94

JavaScriptで組んでたときに、文字の数字を数値型に変換したくて、
"10" + 0
みたいにしてたことを思い出した

**デフォルトの名無しさん** · 2021/08/22(日) 20:28:11.75

C++でしんどいの型の部分じゃないけどな

**デフォルトの名無しさん** · 2021/08/22(日) 20:45:47.91

>>919
JSようしらんけどこれって"100"にならないんだ？

**デフォルトの名無しさん** · 2021/08/22(日) 21:02:27.49

>>862

Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。

以下は公式サイトに掲載されているNimのコード例です。

Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。

import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.

var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]

for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old")

**デフォルトの名無しさん** · 2021/08/22(日) 21:06:05.83

>>862

Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。

以下は公式サイトに掲載されているNimのコード例です。

Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。

import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.

var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]

for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old")

**デフォルトの名無しさん** · 2021/08/22(日) 22:37:49.54

RustにはGCないから云々言われるけどメモリ以外のリソースもRAIIとムーブセマンティクスの力でいい感じに扱えるのは良いよね
他の言語だと with 式などでスコープ抜けたら解放は出来るけど
クロージャにキャプチャされる場合など長時間生き残るようなケースをちゃんと扱えたりするのだろうか

**デフォルトの名無しさん** · 2021/08/23(月) 00:06:22.12

>>921
"100"になるよ

**デフォルトの名無しさん** · 2021/08/23(月) 00:25:43.80

>>898
JavaはグローバルのGCがあるから意味が違うよ。リークしているように見えるがプログラムが正常に
終了をすればGCが起こる（だからJavaは停止時にフリーズしたようになるプログラムが多数）
>>905
ハードルは高くないよ。循環参照をWeak<T>でなくRc<T>で書いてしまえば普通にリークする
リファレンスカウントになっているのだから当たり前だけどね
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html

**デフォルトの名無しさん** · 2021/08/23(月) 01:03:20.75

GC言語にも弱参照はあるのでまともなプログラマーならば強循環参照は作らない
RustはGCが無しでメモリ安全性を保証できる言語であるとともにメモリリークも避けることができる言語

**デフォルトの名無しさん** · 2021/08/23(月) 01:18:03.41

GCは強循環参照も問題なく回収できるんだよ

**デフォルトの名無しさん** · 2021/08/23(月) 01:30:55.93

>>928
GCは方式の異なる段階があって
弱参照を使う循環参照なら強参照カウンタだけで回収できる
強参照のみの循環参照までも回収する方式は様々あるけどいずれも重い
だからGC言語にも弱参照があって賢い配慮あるプログラマーが使えるようになっている

**デフォルトの名無しさん** · 2021/08/23(月) 02:08:47.17

>>926
その日本語訳に書いてる通り

「循環参照は簡単にできることではありませんが、不可能というわけでもありません。 Rc<T>値を含むRefCell<T>値があるなどの内部可変性と参照カウントのある型がネストして組み合わさっていたら、循環していないことを保証しなければなりません;」

RefCell<Rc<T>>を使いこなせるのに循環参照で盛大にリークさせる人も
Rc<T>をWeak<T>に直すのが大変っていう人も
かなりの激レアさんだと思う(個人の感想)

**デフォルトの名無しさん** · 2021/08/23(月) 08:54:29.06

>>929
誤り
GC言語の弱参照は強循環参照対策ではなく、キャッシュなどで長寿命のオブジェクトがGCを妨げることを避ける目的で使用される
だから例えば、ウインドウはボタンを管理しボタンは自身がクリックされたことをウインドウに通知する、ただしボタンが動的に追加削除されることはない、
といったような互いに寿命が一致する循環参照が生じるケースでは弱参照は普通使用しない
マークアンドスイープは十分に高速なので、参照カウンタをGCと併用するのはあまり一般的ではない

**デフォルトの名無しさん** · 2021/08/23(月) 08:57:57.29

ネストしたstructの奥深いところにひっそりRcが隠れてたら
知らない間に循環参照になってることもあるかもしれない

**931** · 2021/08/23(月) 09:17:05.48

念のため補足しておくが、寿命が一致しない循環参照の場合は弱参照を使わなければならないというわけではない
ウインドウとボタンの例でいうと、普通に考えてボタンが動的に削除されようとしていることをウインドウが知らないわけないから、そのタイミングでウインドウが持つボタンへの参照を削除すればいいだけだ
GC言語で弱参照が必要とされるのは極めて特殊なケースに限られており、ほとんど使用されることはない

**デフォルトの名無しさん** · 2021/08/23(月) 09:53:29.91

>>933
特殊なケースではないと思う
GC言語でも何らかのツリー構造をあつかうことはよくあって
その時に親から子へは普通に強参照でも子から親へは弱参照の方が有利だよね
弱参照を使っていれば一部のサブツリーを捨てた時に循環参照ではなくなる
これはGC言語だけではなくRustでも同様で、サブツリーを捨てたらそのトップへの強参照が消えて連鎖的にサブツリーが回収されますよね？

**デフォルトの名無しさん** · 2021/08/23(月) 10:15:02.98

>>934
別に有利じゃないから普通にどっちも強参照使うのが普通だよ
マークアンドスイープは循環参照で遅くなったりしないから

**デフォルトの名無しさん** · 2021/08/23(月) 10:25:19.17

>>935
マークアンドスイープ方式のみでGCする言語ばかりではない
GCは奥が深い
弱参照の使用はそこで有利

**デフォルトの名無しさん** · 2021/08/23(月) 10:28:37.19

ちなみにGC言語は常に強参照を使うことを前提に最適化されているので、必要もないのに弱参照を多用すると確実に遅くなるよ
Javaだと弱参照それ自体がヒープアロケーションされるオブジェクトだったりするので、とんでもなく非効率だ

**デフォルトの名無しさん** · 2021/08/23(月) 10:36:03.26

>>937
Rustでは弱参照を使うデメリットありますか？

**デフォルトの名無しさん** · 2021/08/23(月) 10:50:20.08

>>938
生存期間を意識した非対称なコーディングをしなければならないこと、だね
親子関係の循環参照でどちらを弱参照にすべきかはケースバイケースであり、>>934が思っているほど単純な話ではない
別にRustを批判してるわけじゃないが、GC言語から見ればそれ自体がデメリットなんだよ

**デフォルトの名無しさん** · 2021/08/23(月) 11:23:41.21

これまでRust書いている時にトレーシングGCが欲しくなったことはありますか？
それはどのようなプログラムを書いている時ですか？

**デフォルトの名無しさん** · 2021/08/23(月) 11:40:32.83

>>934
その通り。
ツリーでなくてもある地点から一方向のみの有向グラフになるような強参照の時
そのある地点が解放されれば残りも解放される

**デフォルトの名無しさん** · 2021/08/23(月) 13:03:00.15

PythonやSwiftの自動参照カウント方式はGCとは呼ばない派がいるんだね

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

**デフォルトの名無しさん** · 2021/08/23(月) 13:26:39.80

C++ スレでスマートポインタが GC かどうかという話題が出たことあるわ。
そこで現れた GC の定義としては大まかに

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

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

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

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

**デフォルトの名無しさん** · 2021/08/23(月) 13:46:29.34

>>943
違うよ
GCの定義は明白で
「ガベージが生じて溜まっていってそれらをまとめてコレクションすること」
だからRustで例えばノードツリーのトップが何らか任意の方法でドロップとなった時
連鎖的にツリー全体が次々とRcの強参照カウント0となりツリー全体が解放されるのはGCではない
即座に消えてガベージは溜まって行ってないため

**デフォルトの名無しさん** · 2021/08/23(月) 14:21:58.28

>>944
明白か？
そんな定義は無いと思うが。
GCの起源はLISP由来だと思うけど、その時の実装は参照カウントでは？

**デフォルトの名無しさん** · 2021/08/23(月) 14:28:20.76

あ、すまん。LISPはマークアンドスイープで、その後に参照カウントが発明されてるわ。

**デフォルトの名無しさん** · 2021/08/23(月) 14:53:47.52

>>945
参照カウント方式か否かは焦点ではなくて、ゴミがたまっていってまとめて処理することをgarbage collectionと呼ぶ。
RustのRc利用はゴミがたまっていかないのでGCと呼ばれていない。

**デフォルトの名無しさん** · 2021/08/23(月) 15:46:33.74

>>944
「溜まっていってそれらをまとめて」というのは間違いだな。
wikipediaの記載にある
「不要になった（メモリ）領域を自動的に解放する機能」
というのが正しい。
ポイントは「不要と判断」して「解放」というところ。溜まる必要もまとめて解放する必要も無い。

**デフォルトの名無しさん** · 2021/08/23(月) 16:12:57.05

個人的には GC であるかそうでないかという議論はそれほど意味が感じられない。
GC という切り口からメモリ管理を見ることが出来るという切り口だと考えてる。
極論すれば C の自動変数も「スコープを抜けたら不要 (ということにする) と判断」して「解放」してるので
GC の一種と言えば一種とも見れるし、しかし参照 (ポインタ) が残ってるかもしれないし
それを経由してアクセスしたらワヤになるので (GC としては) 出来が良くねぇなぁってだけのこと。

**デフォルトの名無しさん** · 2021/08/23(月) 16:20:23.00

>>948
Garbage Collectionなのだからゴミ集め
ゴミが溜まったら拾い集めること
RustのRc利用だとゴミは溜まらないので「RustにはGCはない」と世間でも言われている通り

**デフォルトの名無しさん** · 2021/08/23(月) 16:26:13.36

即時解放はGCじゃないと思うわ
スマポも即時解放なのでGCじゃない派

**デフォルトの名無しさん** · 2021/08/23(月) 16:27:26.84

逆に言うと解放のタイミングが基本的に制御できない、つまりIDisposableみたいなのが必要になるならGCという認識

**デフォルトの名無しさん** · 2021/08/23(月) 16:40:48.46

ほとんどの場合に参照が 0 になるより前にゴミになっているが
ゴミであることがわかるのがカウントが 0 になったときなんだ。
カウントが 0 になったときをゴミになったときだと定義づけるのは因果が逆転している。

**デフォルトの名無しさん** · 2021/08/23(月) 16:59:28.87

それは言葉遊びだな

**デフォルトの名無しさん** · 2021/08/23(月) 17:08:30.56

>>953
参照0より前にゴミになった状態を把握する一貫した方法を示せれば貴方が勝てる可能性がある。
示せなければあなたの負け。

**デフォルトの名無しさん** · 2021/08/23(月) 17:39:51.03

>>955
小学生かｗｗｗ勝負してるわけじゃないだろ。
俺は GC とそうでないものを分ける意味があまりないという立場だ。

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

**デフォルトの名無しさん** · 2021/08/23(月) 18:01:17.23

>>948 その基準だとCの自動変数解放もGCになるね。

**デフォルトの名無しさん** · 2021/08/23(月) 18:04:49.13

中間なんてあるか？

**デフォルトの名無しさん** · 2021/08/23(月) 18:20:07.16

>>957
さすがにスタックフレームの移動は含まないんじゃないか

**デフォルトの名無しさん** · 2021/08/23(月) 18:29:19.97

>>959
関数を終える時点でゴミとなるので解放
だからRcと同じ即時解放タイプとなる

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

**デフォルトの名無しさん** · 2021/08/23(月) 18:59:47.21

>>957
システムが不要と判断して開放しているならそうだが、実際には違う。
まだ必要（ポインタとかで参照されている）としている領域でもスコープから抜ければ削除されるから、「不要になった領域を削除する機能」とは言えない。

**デフォルトの名無しさん** · 2021/08/23(月) 19:39:34.81

>>947
まとめて処理しなくてもcollectionだろ。
お前がフィギュアを集めてるとして、欲しいものを溜めて一気に買ってるのか？
定期的に収拾する事自体がcollectionじゃん。

**デフォルトの名無しさん** · 2021/08/23(月) 19:41:33.72

まとめて処理しないとGCではないというのなら
GCのパラメーター変更して毎命令処理の度にGCが走るようにしたらGCではなくなるということ？

**デフォルトの名無しさん** · 2021/08/23(月) 19:43:45.53

与太話はさておきただ単にGCと言うだけでは伝わりにくいから
トレーシングGCとかリファレンスカウント(GC)とか言った方がよいのでは

**デフォルトの名無しさん** · 2021/08/23(月) 19:48:18.23

>>964
そこは論点ではない
リファレンスカウントでも即時解放していればGCではない
ガベージが貯まってから解放処理をしていればGC

**デフォルトの名無しさん** · 2021/08/23(月) 20:08:33.56

所有権を設定して、ブロックスコープを抜けた所有権のある変数はすべて開放とかよく考えたよね

**デフォルトの名無しさん** · 2021/08/23(月) 20:15:04.57

リファレンスカウントは、c++のスマートポインタみたいな循環参照でリークするのと、pythonみたいに循環参照してるゴミを後から回収するのがあるから、後者はリファレンスカウント(GC)と呼ぶべきということでしょ？
前者はGCではない

**デフォルトの名無しさん** · 2021/08/23(月) 21:23:06.49

全く関係ない話するけど、
Rustは、可変参照型の変数を右辺に書いて、moveのソース側にすることは
可能？
それとも、moveのソース側は、普通の所有権がある可変変数でないとダメ？

**デフォルトの名無しさん** · 2021/08/23(月) 21:41:50.19

>>968
moveのソース側って？

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

**デフォルトの名無しさん** · 2021/08/23(月) 21:49:03.56

>>969
let x = 構造体名{初期化メンバの列};
let y = x;
と書いた場合、x の内容がy に moveされるけど、
let mut x = 構造体名{初期化メンバの列};
let z = &mut x;
let y = *z;
とすることは可能？

**デフォルトの名無しさん** · 2021/08/23(月) 22:02:36.97

>>970
なるほどそういうことか
構造体がCopyなら可、Copyじゃなければ不可

**デフォルトの名無しさん** · 2021/08/23(月) 23:33:12.95

GCという言葉がそこまで細かく使わなきゃいけない言葉になってることに意味がない気がする

**デフォルトの名無しさん** · 2021/08/23(月) 23:50:41.85

>>971
Copyって、Cloneじゃなくて POD 的な場合に単純コピーされるというやつの事？

**デフォルトの名無しさん** · 2021/08/23(月) 23:57:23.53

>>973
便乗質問
ムーブで関数に渡してもコピーできない型はcall by valueではなくポインタが渡るのですか？

**デフォルトの名無しさん** · 2021/08/24(火) 00:18:52.33

>>973
Copy はトレイトだがそれ自体はただのマーカーでしかなく特に実装しなければならないメソッドはない。
Copy が実装された型はムーブの文脈でコピーになる (所有権を奪わない)。
https://doc.rust-lang.org/std/marker/trait.Copy.html

clone を (必要な文脈では) 自動で呼ぶってだけ。
複製の仕方は Clone の実装のほうに従う。

**デフォルトの名無しさん** · 2021/08/24(火) 00:33:59.68

>>974
ムーブの実態はビット単位のコピー。
ムーブ元は「今後絶対に使われない」という静的な強力な保証があるから
有効なオブジェクトはひとつだけなんだ。
ビットパターンの複製は作られるよ。

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

**デフォルトの名無しさん** · 2021/08/24(火) 08:40:18.86

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

**デフォルトの名無しさん** · 2021/08/24(火) 08:45:48.38

まあ将来的にはコンパイラーがより賢く・早くなれば循環参照で増え続けるリークに対してコンパイルエラーにも
出来ると思うので、今は未だ、リークする可能性があろうとRustが良い言語だという認識は変わらない。
他の言語でも当然リークチェックは出来るが、GCを前提とするならコンパイルエラーが出ても、なぜエラーなのか
理解しずらいかもしれない。

**デフォルトの名無しさん** · 2021/08/24(火) 08:48:26.31

行数の問題ではなく、Rcを使って独自のデータ構造を作るスキルがあるのに循環参照だけ知らない初心者、というのはレアということでは
まぁそれはそれとして直すのが難しいケースがあるのは同意

**デフォルトの名無しさん** · 2021/08/24(火) 09:23:53.65

・Rustで循環参照が起きるにはRc利用が必須
・Rc利用者は循環参照の存在もそれを避けるWeakの存在も知っている
・したがってRustでメモリリークを生じさせる者はレアケース

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

**デフォルトの名無しさん** · 2021/08/24(火) 12:45:30.39

>>971
なるほど。Rustのオブジェクト型であるところの struct はデフォルトでは
Copy trait は実装されないので、>>970 の後半のように借用を介して
moveのsource側にすることは禁止されているということなのね。

**デフォルトの名無しさん** · 2021/08/24(火) 15:09:04.48

rustってどうやって二重開放のリスク防いでるの？全然ピンとこない

**デフォルトの名無しさん** · 2021/08/24(火) 15:50:18.44

ownershipが１つしかない状態を維持しつつownershipが0になったら（確実に）解放する感じ

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

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

**デフォルトの名無しさん** · 2021/08/24(火) 16:38:09.46

>>977
公式の見解を個人の感想と一緒にするなよ

**デフォルトの名無しさん** · 2021/08/24(火) 17:46:18.00

Rustで循環参照作るの簡単とか言ってるやつは100%エアプだからほっといてやれ
他言語での経験をあたかもRustで経験したかのように語りたかったんだろう