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/ 892 名前：デフォルトの名無しさん [2021/08/22(日) 03:11:53.65 ID:0Cz6ueFz.net] >>862 普通オブジェクトなんて参照だろ、って事で Nim では以下のように書くのが慣例化しています。 type Point = ref PointObj PointObj = object x: int y: int proc print(this: Point) = echo "x = ", this.x, ", y = ", this.y this.x = 100 var p = Point(x: 10, y: 15) p.print() echo "x = ", p.x, ", y = ", p.y オブジェクトとそのリファレンスを同時に定義して、通常使わない方のオブジェクト側にサフィックスをつけておくと、まぁ素のオブジェクトも作りたきゃ作れるし、って話です。 自分は正直リファレンスだけで良いので更に手を抜いてこう書きますけどね。 type Point = ref object x: int y: int 893 名前：デフォルトの名無しさん [2021/08/22(日) 03:16:29.28 ID:0Cz6ueFz.net] >>862 パターンマッチ？case でしょ？ Nim も case でそれっぽく書けます。 複式パターン fn main() { let x = 1; match x { 1 | 2 => println!("1 | 2"), 3 => println!("3"), _ => println!("other"), } } let x = 1 case x of 1, 2: echo "1 | 2" of 3: echo "3" else: echo "other" 894 名前：デフォルトの名無しさん [2021/08/22(日) 03:20:10.82 ID:0Cz6ueFz.net] >>862 範囲 fn main() { let x = 1; match x { 1...5 => println!("1...5"), _ => println!("other"), }; } let x = 1 case x of 1..5: echo "1..5" else: echo "other" 895 名前：デフォルトの名無しさん [2021/08/22(日) 03:23:05.87 ID:0Cz6ueFz.net] >>862 case の返りを受け取る fn main() { let x = 1; let s = match x { 1 => "one", 2 => "two", _ => "other", }; println!("{}", s) } let x = 1 let s = case x of 1: "one" of 2: "two" else: "other" echo s 896 名前：デフォルトの名無しさん [2021/08/22(日) 03:24:44.35 ID:0Cz6ueFz.net] >>862 分配束縛 Nim は標準ではできませんが https://github.com/andreaferretti/patty を突っ込むことで可能です。 897 名前：デフォルトの名無しさん [2021/08/22(日) 03:26:55.98 ID:0Cz6ueFz.net] >>862 仕様バグがない Rust の以下の挙動は全く理解ができません。 fn main() { let x = 'x'; let c = 'c'; match c { // x: c c: c x => println!("x: {} c: {}", x, c), } // x: x println!("x: {}", x) } 普通 x にマッチすると思わないでしょこれ。 さらにその直後 x が 'c' に変わってるとか予想だにしませんよ。 まぁ普通はこんな書き方しないと思いますがこんな調子ではどこでどうハマるか予測不可能です恐ろしすぎます。 Nim はこんな書き方そもそも出来ません。 898 名前：デフォルトの名無しさん [2021/08/22(日) 03:31:02.98 ID:0Cz6ueFz.net] >>862 コンパイラがケチくさくない nim c -r hoge これで hoge.nim をコンパイルします。 拡張子なんて指定する必要ありません。 -r で実行もします。 Rust の場合 rustc hoge <- ダメ コンパイルと同時に実行しようと思ったら rustc hoge.rs && ./hoge うーん・・・ 899 名前：デフォルトの名無しさん [2021/08/22(日) 03:36:37.77 ID:0Cz6ueFz.net] >>862 実行速度・メモリ使用量・ファイルサイズが小さい Rust と比べて Nim の実効速度はどっこいかむしろ速いです。 Rust はこんだけイライラする書き方を強制されるにも関わらずたいして速くないとかもう哀れすぎます。 コンパイル後のファイルサイズは話にならないレベルで比べ物になりません。 fizzbuzz の例(FizzBuzz を無駄にベンチマークしてみた By Nim、golang、Rust、Crystal、その他 - 強まっていこう)で言うと 項目 　　　　　Nim 　　　　Rust 実行速度 　0.37s 　　　　0.44s ファイルサイズ 　82K 　　　　3.4M メモリ 　　　　　356K 　　　　900K こんな感じです。 900 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 03:40:59.41 ID:EcXIWh+x.net] >>882 無知がやるとそうなるわな 901 名前：デフォルトの名無しさん [2021/08/22(日) 08:37:49.63 ID:0Cz6ueFz.net] >>883 >無知がやるとそうなるわな バカ丸出し Nimは標準実装されたnimコンパイラが強力なマクロで 最適化されたCのソースコードを吐き出して、Cコンパイラ で極小バイナリまで生成するから、コンパイルするだけで 後はプログラマがする仕事が無いので怠けててもいい Rustは標準実装されたコンパイラでコンパイルするだけでは 超巨大なバイナリを生成するので、最適化せれたチューニング を施して小さなバイナリを生成� 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ではなくポインタが渡るのですか？

---

---

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

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