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/ 902 名前：ｵなければならないから プログラマの仕事が増えて怠けられない [] [ここ壊れてます] 903 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 08:40:06.97 ID:BRNN665g.net] >>884 仕組みすら理解してないのか 904 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 08:43:57.27 ID:c6eQFYhO.net] >>880 それはブロックスコープといって多くの言語が備えておりプログラミングの基礎です まさかNimには存在しないのですか？ 905 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 08:57:00.52 ID:QorwbXcj.net] rustスレでnim nim言ってる奴荒らしだろ 906 名前：デフォルトの名無しさん [2021/08/22(日) 09:00:12.62 ID:0Cz6ueFz.net] >>862 マクロのシンタックスを別で覚える必要がない Rust のマクロは構文が全く変わってしまいます。 そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。 公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに 由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で 「なんじゃそりゃ」と言う言葉しか出ません。 Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための 障壁の低さは比べ物になりません。 907 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 09:19:59.80 ID:k4RSCji3.net] 次世代言語22 Go Nim Rust Swift Kotlin TypeScript https://mevius.5ch.net/test/read.cgi/tech/1629590343/ 908 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 09:21:24.81 ID:k4RSCji3.net] nim https://mevius.5ch.net/test/read.cgi/tech/1519896738/ 909 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 09:49:19.77 ID:sxhQ+hXZ.net] 実際rustって色々リンクするから、最小バイナリでかいよな でも、それで困ったことってあるか？ 俺はない 910 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 09:53:06.17 ID:DrnSGK6Q.net] >>891 それはリンクする状況にするからであってRustのせいではない 例えばRustを使って組み込みやWASM等でもバイナリでかいと思ってないよね 911 名前：デフォルトの名無しさん [2021/08/22(日) 10:05:41.39 ID:qkR4Cuiq.net] Rustは他に比べれば最小のバイナリでしょ、コンパイラ/リンカーが長い年数を掛けて最適化されたCより大きいが。 一番不満なのが公式はビルドが速いというがそんなに早くない事だけ。それ以外は従来のC/C++（C++17/20/23 なんかを除く)より圧倒的に安全だし、明示的であるからこそタイプ量が多い。 Nimに比べて大きいというのはRustのコンパイラがまだCを吐き出してた頃から最適化されていないから、Nimと いうかGCCやClangに比べ、ほんの少し大きくなる。リンクするものが大きければバイナリが大きくなるのは 当然でGoなんかはまさにそれでしょ、goroutineを共有ライブラリに押し込めることは出来ないから 912 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 10:06:16.71 ID:sxhQ+hXZ.net] >>892 まあ、ユーザコード自体のサイズがでかいわけじゃないのは同意 913 名前：デフォルトの名無しさん [2021/08/22(日) 10:17:01.78 ID:qkR4Cuiq.net] もう１つ不満がある事は、Rustならメモリーリークしないと言う奴がいる事、公式も明言してる通り グローバルの循環参照を作成してしまえば簡単にリークするのに、意識高い系のコード書かないやつが メモリーリークしないんだと他の言語も触ったことの無い初心者に力説する事。盛大にリークしてて 正常に動いてるプログラムを直すのは大変・・・ ま、これは言語のせいじゃないけどね、他は凄い良く出来てる、Linuxカーネルに採用されるような 他の言語（第３の言語）は当分出てこないだろうと思うほど 914 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 10:35:44.30 ID:FTtcJrTl.net] Rustのメモリ安全性は、メモリリークしない、ではないからな。 915 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 10:40:22.74 ID:VB7b1YKz.net] >>895 Rustは弱参照があるから強参照の循環参照を作らずに済みます　 よってまとまなプログラミングをしていればメモリーリークは起きません 916 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 10:42:20.85 ID:sxhQ+hXZ.net] >>895 javaでも同じことを言う奴がいる 「GCが頻発する。GC壊れてる」 壊れてるのはお前のコードだ 917 名前：ハノン mailto:sage [2021/08/22(日) 10:52:46.02 .net] >>867 構ってあげるから別スレ建ててください C へのトランスレータであることは魅力的ですよね 918 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 10:54:43.87 ID:j+Q/a+4n.net] >>895は分かってる人だろう ちゃんと読んでるか？ 919 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 11:49:45.30 ID:PExPKGEq.net] ビット全探索する関数作ったヽ(´ー｀)ノ 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()); など 920 名前：デフォルトの名無しさん [2021/08/22(日) 12:16:08.62 ID:0Cz6ueFz.net] >>862 Rust の良いところ さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。 Rust にも良いところはあります。 fn <- 短い！ proc <- 長い！ これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。 しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、 何故ここだけすっきりしているのやらさっぱり意味がわからないです。 あ、結局ディスってもうた・・・。 921 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 12:22:55.13 ID:pVXVequb.net] >>902 どうでもいいだろ それが0文字の言語も8文字の言語も併用しているが長さで困ったことはない タイプ数を気にするのは愚か者だけだ 922 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 12:30:03.84 ID:zDmwJZXZ.net] この仕組みを教えて下さい もしかして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. 923 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 12:37:43.49 ID:vEK5NNFF.net] >>895 他の言語に比べれば循環参照を作るハードルはかなり高いでしょ 現実的な用途でborrow checkerに引っかからないような循環参照を作って リーク以外は機能的に問題ないコードを書くのは初心者には難しいと思う 924 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 12:55:40.93 ID:QorwbXcj.net] さすがにマルチポストは荒らし以外の何物でもないな 925 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 13:03:58.26 ID:sxhQ+hXZ.net] >>904 the compiler will collapse the discriminant of the first option into the second. って言ってるから Option<Option<u8>>はOption<u8>に変換されるってことじゃない？ 926 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 13:18:58.50 ID:cSh20jP2.net] >>554-555 あたりが物になるのはいつかなぁ 組み込みだとLLVM縛りは結構きつい 927 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 13:46:33.46 ID:j+Q/a+4n.net] >>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 928 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 14:20:53.63 ID:sxhQ+hXZ.net] 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か区別してるのかな 929 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 14:35:04.66 ID:vEK5NNFF.net] [0..=3]<u8>になってるね nightlyで#[rustc_layout(…)]を使うと確認できる #![feature(rustc_attrs)] #[rustc_layout(abi, size, debug)] type Foo = Option<Option<Option<u8>>>; 930 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 15:31:41.81 ID:PExPKGEq.net] Itertoolsが便利すぎて今までの自分が可愛そうすぎる(´･ω･`) 931 名前：デフォルトの名無しさん [2021/08/22(日) 17:33:05.93 ID:0Cz6ueFz.net] >>862 技術書典に出会っていなかったら俺はNimをさわってないと思う 背景 俺たち「そろそろ技術書典に参戦するか」 俺たち「何書く？」 俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」 ワイ「(マイナーの定義はさておき)Nimでオナシャス」 ワイ「(アドカレあるし、記事まとめておくかぁ...)」 Nimとは？ Nim は アンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、 コンパイル言語という特徴を持つプログラミング言語です。 アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々 な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。 それがNimプロジェクトの始まりで、2005年頃のようでした。 当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から 2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。 932 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 18:20:04.94 ID:qHvaNpwK.net] 結局rustもC++を遥かに超える型地獄なんだな 933 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 18:47:16.61 ID:eu6eNh6V.net] こんだけ型がっちがちに固められた言語触っちゃったら他の言語に戻れない PythonとかPythonとか 934 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 19:10:19.80 ID:E7wqFzW/.net] 型地獄って何？ 935 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 19:11:44.78 ID:CqI7brJQ.net] 二度と出られぬかーたーじーごーくーーー 936 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 19:15:51.20 ID:+34cYDX+.net] 実行時にバグるよりコンパイルエラーでコンパイル出来ない方が遥かに優れていると思ってるけど, そう思わないと型が辛くなるだろうなぁ 937 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 19:27:07.94 ID:PExPKGEq.net] JavaScriptで組んでたときに、文字の数字を数値型に変換したくて、 "10" + 0 みたいにしてたことを思い出した 938 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 20:28:11.75 ID:O/1WEaVf.net] C++でしんどいの型の部分じゃないけどな 939 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 20:45:47.91 ID:JES5Vdct.net] >>919 JSようしらんけどこれって"100"にならないんだ？ 940 名前：デフォルトの名無しさん [2021/08/22(日) 21:02:27.49 ID:0Cz6ueFz.net] >>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") 941 名前：デフォルトの名無しさん [2021/08/22(日) 21:06:05.83 ID:0Cz6ueFz.net] >>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") 942 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 22:37:49.54 ID:Wmq9vv9f.net] RustにはGCないから云々言われるけどメモリ以外のリソースもRAIIとムーブセマンティクスの力でいい感じに扱えるのは良いよね 他の言語だと with 式などでスコープ抜けたら解放は出来るけど クロージャにキャプチャされる場合など長時間生き残るようなケースをちゃんと扱えたりするのだろうか 943 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 00:06:22.12 ID:q1PbYAS3.net] >>921 "100"になるよ 944 名前：デフォルトの名無しさん [2021/08/23(月) 00:25:43.80 ID:WImWpxqb.net] >>898 JavaはグローバルのGCがあるから意味が違うよ。リークしているように見えるがプログラムが正常に 終了をすればGCが起こる（だからJavaは停止時にフリーズしたようになるプログラムが多数） >>905 ハードルは高くないよ。循環参照をWeak<T>でなくRc<T>で書いてしまえば普通にリークする リファレンスカウントになっているのだから当たり前だけどね https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html 945 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 01:03:20.75 ID:LyXSTYiq.net] GC言語にも弱参照はあるのでまともなプログラマーならば強循環参照は作らない RustはGCが無しでメモリ安全性を保証できる言語であるとともにメモリリークも避けることができる言語 946 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 01:18:03.41 ID:9dmEVPj+.net] GCは強循環参照も問題なく回収できるんだよ 947 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 01:30:55.93 ID:gt/OOSS+.net] >>928 GCは方式の異なる段階があって 弱参照を使う循環参照なら強参照カウンタだけで回収できる 強参照のみの循環参照までも回収する方式は様々あるけどいずれも重い だからGC言語にも弱参照があって賢い配慮あるプログラマーが使えるようになっている 948 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 02:08:47.17 ID:mUiDivSN.net] >>926 その日本語訳に書いてる通り 「循環参照は簡単にできることではありませんが、不可能というわけでもありません。 Rc<T>値を含むRefCell<T>値があるなどの内部可変性と参照カウントのある型がネストして組み合わさっていたら、 循環していないことを保証しなければなりません;」 RefCell<Rc<T>>を使いこなせるのに循環参照で盛大にリークさせる人も Rc<T>をWeak<T>に直すのが大変っていう人も かなりの激レアさんだと思う(個人の感想) 949 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 08:54:29.06 ID:7vUkULmy.net] >>929 誤り GC言語の弱参照は強循環参照対策ではなく、キャッシュなどで長寿命のオブジェクトがGCを妨げることを避ける目的で使用される だから例えば、ウインドウはボタンを管理しボタンは自身がクリックされたことをウインドウに通知する、ただしボタンが動的に追加削除されることはない、 といったような互いに寿命が一致する循環参照が生じるケースでは弱参照は普通使用しない マークアンドスイープは十分に高速なので、参照カウンタをGCと併用するのはあまり一般的ではない 950 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 08:57:57.29 ID:ksTslrDC.net] ネストしたstructの奥深いところにひっそりRcが隠れてたら 知らない間に循環参照になってることもあるかもしれない 951 名前：931 mailto:sage [2021/08/23(月) 09:17:05.48 ID:7vUkULmy.net] 念のため補足しておくが、寿命が一致しない循環参照の場合は弱参照を使わなければならないというわけではない ウインドウとボタンの例でいうと、普通に考えてボタンが動的に削除されようとしていることをウインドウが知らないわけないから、そのタイミングでウインドウが持つボタンへの参照を削除すればいいだけだ GC言語で弱参照が必要とされるのは極めて特殊なケースに限られており、ほとんど使用されることはない 952 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 09:53:29.91 ID:IzWPiInz.net] >>933 特殊なケースではないと思う GC言語でも何らかのツリー構造をあつかうことはよくあって その時に親から子へは普通に強参照でも子から親へは弱参照の方が有利だよね 弱参照を使っていれば一部のサブツリーを捨てた時に循環参照ではなくなる これはGC言語だけではなくRustでも同様で、サブツリーを捨てたらそのトップへの強参照が消えて連鎖的にサブツリーが回収されますよね？ 953 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 10:15:02.98 ID:6chE64yn.net] >>934 別に有利じゃないから普通にどっちも強参照使うのが普通だよ マークアンドスイープは循環参照で遅くなったりしないから 954 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 10:25:19.17 ID:9/DhhYFq.net] >>935 マークアンドスイープ方式のみでGCする言語ばかりではない GCは奥が深い 弱参照の使用はそこで有利 955 名前：デフォルトの名無しさん mailto:sage [2021/08/23(月) 10:28:37.19 ID:6chE64yn.net] ちなみにGC言語は常に強参照を使うことを前提に最適化されているので、必要もないのに弱参照を多用すると確実に遅くなるよ Javaだと弱参照それ自体がヒープアロケーションされるオブジェクトだったりするので、とんでもなく非効率だ 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 小学生かｗｗｗ 勝負してるわけじゃないだろ。 俺は 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が１つしかない状態を維持しつつownershipが0になったら（確実に）解放する感じ ownershipはどこかの変数が直接的or間接的に保有してて 同じリソースに複数のownershipが発生しないように 代入とか関数の受け渡しでmoveしたりborrowしたりする 少し逸れるけど解放処理を必要としないデータはCopy可能な場合が多い ownershipは「所有権」て訳されるけど意味的には「解放権」とか「解放責任」に近いかも

---

---

[ 続きを読む ] / [ 携帯版 ]

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