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/ 638 名前：デフォルトの名無しさん mailto:sage [2021/08/16(月) 10:30:33.78 ID:rx7L9F9W.net] (while true のような実質無条件ループを除き)条件付きループをbreakで抜けるのは可読性を下げる要因になるから一般的にはRustに限らずできるだけ避けるだろ 悪い作法を推奨するような機能は付けるべきではない 639 名前：デフォルトの名無しさん [2021/08/16(月) 10:39:16.03 ID:WTBg47DG.net] ほぉたしかにそうゆうのあれば便利な時もありそう macroで似たような物は作れそうな気がする たしかにlispとかでもwhileはnil returnだな(´・ω・｀) 640 名前：デフォルトの名無しさん [2021/08/16(月) 12:47:44.44 ID:meTevnZp.net] >>626 forでお目当てのものが見つかったらその時の値を欲しい時 当然そこで打ち切りたいから普通にbreakすると思うが君は回り続けるのかね？ 641 名前：デフォルトの名無しさん mailto:sage [2021/08/16(月) 14:09:14.90 ID:ScFkjf4y.net] >>628 打ち切りたいなら、take_whileの結果を対して回せばよくね？ 642 名前：デフォルトの名無しさん mailto:sage [2021/08/16(月) 14:32:54.40 ID:ebJKRLr3.net] 手間かけて機能拡張するほどのメリットがないってことだろうね https://github.com/rust-lang/rfcs/issues/1767#issuecomment-292678002 643 名前：デフォルトの名無しさん [2021/08/16(月) 16:29:22.27 ID:RqqPeHPy.net] つまりforやwhileではなくiterを使うかloopを使えってことか 644 名前：デフォルトの名無しさん mailto:sage [2021/08/16(月) 16:36:53.53 ID:iL7TnNF0.net] awaitとか ? が絡むとループ使いたい場合はあるかもね 645 名前：デフォルトの名無しさん [2021/08/16(月) 16:57:08.35 ID:QDTL5fKB.net] >>632 それらメソッドチェーン部分ではもちろん使えるけど iter系で指定するクロージャの中でも使えるんだっけ？ 646 名前：デフォルトの名無しさん mailto:sage [2021/08/16(月) 20:57:35.53 ID:iL7TnNF0.net] >>633 Item が Option や Result なら ? は使えるけど await は async fn か async block の中でしか使えないからほぼ使えないと思ってよさそう 647 名前：デフォルトの名無しさん [2021/08/16(月) 22:05:08.22 ID:bBW7ChkS.net] featuresは？ 648 名前：デフォルトの名無しさん [2021/08/16(月) 23:25:05.01 ID:e18AJ9DT.net] >>634 ?の方だけど、NoneやErrを除外してSomeやOkの皮を外すのはfilter_map使わないとメンドイね 例えばこんな感じで「?」はクロージャ内で使えた println!("{}", std::env::args().filter_map(|x| std::char::from_u32(x.parse::<u32>().ok()?+110)).collect::<String>()); 実行結果 $ cargo run 4 test 7 5 987654321 6 rust 649 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 01:06:37.74 ID:diXkc4zq.net] >>636 これは filter_map よりも map().collect::<Result<String, _>>() の方がよさそう 650 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 01:42:37.78 ID:2Xo4qCNa.net] 全く関係ないけど、 for x in v には、 for x in &v for x in &mut v for x in v.iter() のようなバリエーションもあるようだけど、 for &x in v のような書き方も出来るの？ あと、v と書いても v.iter() の省略なの？ この辺の話はどこに書いてる？ 651 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 01:44:24.62 ID:2Xo4qCNa.net] >>638 ついでに、 let x = &y; は、 let &x = &y; let &x = y; みたいに書くことも出来るの？？？ 652 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 01:46:10.93 ID:yPn/BtRt.net] >>638-639 左辺と右辺はパターンマッチで対応するメカニズムになっている。 653 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 02:15:00.92 ID:Ok9gkDKS.net] >>638 forの展開はこ� 654 名前：ﾌ辺とか。.iter()じゃなくて.into_iter()やね https://doc.rust-lang.org/reference/expressions/loop-expr.html#iterator-loops [] [ここ壊れてます] 655 名前：デフォルトの名無しさん [2021/08/17(火) 03:20:14.87 ID:q/ldIEfm.net] この言語の敷居の高さの上げ方は異常すぎる。誰も全容分かってない 656 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 03:39:07.39 ID:yPn/BtRt.net] C++ よりマシ。 657 名前：デフォルトの名無しさん [2021/08/17(火) 04:00:51.74 ID:run+2ZVZ.net] それだと最初のエラーを拾ってしまうけど今回はエラーになる引数を与えてそれらを無視して拾い集めるコード もしエラーにならない引数だけを与えて成功するコードならばその方針もいいかも あとfrom_u32はOptionを返すのでResultでなく全体をOptionにするとして 最後にunwrapも必要なのでmap().collect()のコードは以下になると思いますが 元の>>636より長くなってしまいますね println!("{}", std::env::args().skip(1).map(|x| std::char::from_u32(x.parse::<u32>().ok()?+110)).collect::<Option<String>>().unwrap()); 実行結果 $ cargo run 4 7 5 6 rust 658 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 09:39:00.09 ID:Wyc5eeHq.net] 小中学生あたりでもわかる本ある？ 659 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 09:48:35.92 ID:uTdncVPo.net] きったねぇコードだな 660 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 13:39:50.79 ID:hwU1GG4D.net] 参照型の変数xをlet文で新しい変数yの初期値にした場合、 let a = 123; let x:&i32 = &a; let y = x; y は参照型になるんだっけ？ そもそも、最初の文は let x = &a; と書いても全く同じ意味だっけ？　さらに、 let x:&i32 = a; と書いても同じ？ 661 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 14:30:13.21 ID:082KifEP.net] >>647 試してみるといいよ yの型を知りたければtype_of(&y)で fn type_of<T>(_: &T) -> &str { std::any::type_name::<T>() } let a = 123; let x = &a; let y = x; println!("{}:{}, {}:{}", x, type_of(&x), y, type_of(&y)); 662 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 14:31:53.69 ID:hwU1GG4D.net] 答えを知ってる人に書いて欲しい。 この言語、試してみないと型すら分からないんだったら困るな。 663 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 14:35:58.73 ID:Ok9gkDKS.net] >>647 > y は参照型になるんだっけ？ なる > そもそも、最初の文は > let x = &a; > と書いても全く同じ意味だっけ？ ほぼ同じ 下だとaの型がi32に固定されない点だけ違う > さらに、 > let x:&i32 = a; > と書いても同じ？ これは全然違う そもそも型エラーでコンパイルできない 664 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 14:41:24.86 ID:QXNoWfC2.net] >>647 めちゃ基本的なことなので入門書を読もう 665 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 14:45:56.55 ID:hwU1GG4D.net] 本を読んだけど、明確には書いてなかったと思う。 let文に置いて参照型が右辺の場合、左辺も参照型になるということなのか。 ということは、letを書かない代入文で左辺に参照型で無い型を 書いて、右辺に参照型がある場合にはエラーになるのか？？？ わけが分からん。 666 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 14:51:57.21 ID:WvkHdE3s.net] C++出身の人かな 667 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:00:35.72 ID:hwU1GG4D.net] C++出身だ。 Rustにおける参照型の変数の規則性が分からない。 668 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:06:15.30 ID:Ok9gkDKS.net] >>654 Rustの参照はC++の参照じゃなくてポインタのほうが近いよ 669 名前：デフォルトの名無しさん [2021/08/17(火) 15:06:32.93 ID:uFWUzCTr.net] Rustから入る人や 色々な言語をやってきた人は理解が早い しかしC++だけやJavaだけしか経験ない人は 自己中な思い込みが激しくて素直に学習しようとせずに間違った解釈したりして無駄な質問ばかりしがち 670 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:06:36.98 ID:hwU1GG4D.net] Rustは例はあるが、ちゃんとした論理的な言葉や数式の様なもので、規則性が 書いてないのではない？ C++だともっと厳密に書いてある。 671 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:10:48.52 ID:+ZvfT+RK.net] >>652 何て本？ 672 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:11:29.96 ID:hwU1GG4D.net] >>656 そうではなくて、規則性を言葉で書いてくれ、ということだよ。 試してみてなんとなくの経験法則とかじゃなく。 673 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:12:37.71 ID:hwU1GG4D.net] >>658 bookの印刷版も読んだが、途中読み飛ばしたページもあるが 読んだところにはちゃんと書いてなかったと思う。 数学的な規則が欲しいんだ。 文学的な言葉や例ではなく。 674 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:13:56.74 ID:Ok9gkDKS.net] >>657 そういう位置付けのドキュメントはこれだね ただし冒頭にもある通り完全ではない The Rust Reference https://doc.rust-lang.org/stable/reference/ 675 名前：デフォルトの名無しさん [2021/08/17(火) 15:15:28.48 ID:Y5PdM7En.net] >>656 まずはC++を忘れろ 思い込みは習得の邪魔になる あるいは様々な言語をやってきていれば各言語で概念や書式や用語などが少しずつ異なることが理解できるはずだ 676 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:18:24.83 ID:hwU1GG4D.net] >>662 めんどくさいので試してないんだよ。 試さなくても数学の用に読んで理解できる規則が欲しい。 Cのポインタは難しいとされるが、俺は数学が得意なので本を読んだだけで 完璧に理解できた。 C++探せばちゃんと書いてある本がある。 677 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:23:08.50 ID:hwU1GG4D.net] >>661 BNFで書いてあるようだが、具体的にどこに書いてあるか示してくれ。 ちなみにBNFだと意味論までは語れ無い事があるので無理かも知れない。 678 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:24:30.00 ID:+8wra73u.net] 「俺は数学が得意なんだ！」 ワロタ いつものBoxおじいさんじゃん 679 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:24:31.45 ID:hwU1GG4D.net] 目次を見てもReferenceの文字が見当たらないが。 C++だとちゃんとあるぞ。 どうしてReferenceも型のはずなのに、目次すらないんだよ。 680 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:25:31.33 ID:hwU1GG4D.net] >>665 トップだったからな。 681 名前：デフォルトの名無しさん [2021/08/17(火) 15:27:48.00 ID:bPhCjiXF.net] >>660 そこまで言うならば十数種類あるRustドキュメントのうち、 editionとapiとstdとreferenceとtheとcookとexampleあたりにあとはcliとasyncくらいまでが基礎かな。 あと外部たがcargoとrustcにrustdocなどのbookも。 unstableやnomiconは後でいい。 wasmやembedded系bookも必要なら。 682 名前：デフォルトの名無しさん [2021/08/17(火) 15:28:18.82 ID:jTG+Bjsl.net] IQ87の人でしょ 相手しちゃダメ 683 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:29:44.40 ID:hwU1GG4D.net] >>668 なんで、この言語に置いて最も重要な型の一つの規則性がそんな何千ページもの 本を読まないと解説されてないんだよ。 684 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:30:14.32 ID:hwU1GG4D.net] >>669 お前の友達と一緒にすんな。 685 名前：デフォルトの名無しさん [2021/08/17(火) 15:35:47.16 ID:JF4CPCdG.net] >>667 数学得意ならRustも深く理解しやすい 強い静的な型システムの元にある そして生死貸借も明確で数学的にメモリ安全性を保証 利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない 686 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:44:19.09 ID:hwU1GG4D.net] >>672 さっきから聞いているのに、ちゃんとした論理的規則を語った人は誰も居ない。 つまり、今このスレに居る人達は誰も理解してない証拠だろう。 つまりこれは、Rustが試してみないと分からない言語だからではないか。 687 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:46:21.18 ID:diXkc4zq.net] >>673 5chじゃなくて users.rust-lang.org あたりで聞いてみたら 専門家がいっぱいいるよ 688 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:48:51.11 ID:hwU1GG4D.net] >>674 参照型はRustにとって最重要の型。 それがそんなところに質問しなければ分からないというのは困ったことだぞ。 689 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:56:13.41 ID:UjpqRJxn.net] ポインタを理解するのにもRustを理解するのにも数学の得意不得意は関係なくね？ ポインタを理解できない人をあまり多く見たことがないから実際のところどうなのかよく分からないんだが 690 名前：デフォルトの名無しさん [2021/08/17(火) 15:57:56.00 ID:U4J278+6.net] >>670 どこにも記述されていないことを君が自己中心的な思い込みで間違いなく判断や間違った推測をしているから>>647や>>652の書き込みになっている let文や呼び出し引数はirrefutable pattern matchingであり各種destruturingはあっても個々の型は対応する Tと&Tがmatchingすることはない 691 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 15:59:25.04 ID:hwU1GG4D.net] >>677 どから、それがどこに書いているのかリンクを張ってくれ。 あなたの独自説ではなく、公式のな。 692 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 16:06:26.36 ID:KRsjniKD.net] >>672 >利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない rustではcoercionと呼んでるものが暗黙の型変換だぞ 693 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 17:16:17.31 ID:uVOQbHaf.net] グリーンスレッド何それ？さんだっけ？ 694 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 17:20:32.19 ID:apgY8ckc.net] 公式の言葉が欲しいってならreferenceのlet statement, reference patternsあたりでもみりゃいいんじゃないっすかね知らんけど 695 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 17:32:50.74 ID:fMgDzJWA.net] rustは思ったより流行りそうにないなぁ。 使用者爆発的に増えてくるハズがC++知らん人は そもそも使う層じゃないし、 C++知ってる人は、逆にめんどくさいから様子見、流行らなければスルー ぐらいかね。 696 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 18:03:44.37 ID:PENy3uzh.net] ぶっちゃけ1言語のみしか使えないようなプログラマが有能だとはとても思えないが 実際にそういう人はいるけど融通効かないし生産性が高いとも思えない 所詮ドカタじゃないの 697 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 18:14:54.04 ID:yPn/BtRt.net] >>682 C++ で疲弊した人が Rust に移ってるってのはあるぞ。 698 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 18:21:01.37 ID:diXkc4zq.net] >>675 だからそう主張してくればよいじゃん ここにいる人じゃ話にならないんでしょ？ 699 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 20:01:51.20 ID:uTdncVPo.net] 疲弊というかドロップアウター 700 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 21:03:40.91 ID:iE5VyQYC.net] >>647 上３つの式は正しいのに、なんで下２つの式はそうなるのか 701 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 21:04:44.45 ID:iE5VyQYC.net] >>687 見間違えた 一番下の式だけだね 702 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 21:18:21.30 ID:sY2NwSu8.net] 実際はc++わからんけどrustわかればマウント取れそうじゃね？って馬鹿しか手を出してないという現実。 703 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 21:24:14.87 ID:hwU1GG4D.net] Rustは、GoogleTrendsでは他の言語に比べて低空飛行だけど(Kotlinと同じくらい ではあるが)、他の言語が下がる傾向があるのに対してRustだけは少しずつ上がってる。 Stackoverflowでは既にC++の30%〜40%位まで質問の量が迫ってきているとか。 なので良く分からない。 GoogleTrendsが実際と合ってないという説も見かけた。 704 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 21:26:37.22 ID:hwU1GG4D.net] crates.ioでcrateをダウンロードされた回数が20億回を越えていたり、 投稿されたcrateの数が3万種類を超えたりとか。 20億回というのはとんでもない大きな数字。 全世界のプログラマの数は2,500万人くらいだそうだから相当な数だ。 良く分からないくらい異常に大きな数値。 705 名前：デフォルトの名無しさん [2021/08/17(火) 21:35:56.30 ID:hYkkAkQv.net] iocrateはきっと誰かがwhile true do; cargo build; cargo clean;doneみたいの流し続けたんだろ c++よりマシなのは確かだがredosだかみたいの全然進まんしc++,cな代替物にはなれなさそう tech giantsみたいな連中が根幹部分rustに変えるみたいな事言ってるけど流行ってる感じ全然しないよね(´・ω・｀) 706 名前：デフォルトの名無しさん [2021/08/17(火) 21:40:50.24 ID:jTG+Bjsl.net] 久しぶりに流行ってない流行らないアピールきてるね 707 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 21:41:43.37 ID:LO76a4+c.net] 土方では流行らないでしょ 708 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 21:45:28.03 ID:yac5fWyQ.net] リポジトリの分散化考えないとマジ負荷が半端無さそう 709 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 21:49:53.88 ID:fMgDzJWA.net] rustで作ったライブラリは他の言語から使いやすいんかい？ c\c++置き換えるなら、むしろそここそ一番重要かもしれん。 710 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 22:12:04.05 ID:53TH2cCY.net] >>696 Rustのライブラリは他言語からは使いにくいのが問題になっていると聞いたが。 多分、C/C++のライブラリのようにはいかないと思う。 711 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 22:14:00.60 ID:53TH2cCY.net] >>692 前半、なるほど。 githubで最高人気であるところのvue.jsも、いいねは2万くらいだったと思うし。 なんか数値に異常さを感じる。 712 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 22:16:21.15 ID:53TH2cCY.net] vue.jsのgithubでのStar数は、18万7,000だった。 crate.ioのダウンロード回数はこの1万倍を越えている。 普通に使っているだけでは辻褄が合いそうに無いな。 全世界の全てのプログラマが100回くらいcrateをダウンロードしたことになる。 713 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 22:54:36.64 ID:Ok9gkDKS.net] crates.ioのDL数と比較すべきはnpmのDL数では？ https://www.npmtrends.com/vue 714 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 00:15:56.99 ID:24ORvnDg.net] crates.ioのダウンロード数は依存crateのCIが走る度に増えるようなものだからそりゃ多くなるでしょ GitHubのstarと比較したのはなぜ？ 715 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 00:33:37.55 ID:c7Y+RcIr.net] 別にプログラマが手動でダウンロードするわけではないんだが… 1回コンパイルすると100個以上落としてくるのも普通だから 2千万回コンパイルが実行された、という程度の話 ざっくり5年で均せば1日1万回ってとこか 716 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 01:06:03.53 ID:WOvB8ChX.net] CIだろうね。人がcargoを直に打ってるとは思えん 717 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 01:16:27.76 ID:wcIqldgw.net] 強力にキャッシュが効くはずのCIでツールが未整備なために効かず 異常にDL数が伸びてしまっただけだろう 718 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 04:35:06.87 ID:AXrkZvXQ.net] CIのライブラリインストールが動画の次に無駄な帯域を食ってると言われているだけある 719 名前：デフォルトの名無しさん [2021/08/18(水) 09:18:01.26 ID:k0LDI8WO.net] >>639 難しく考えすぎ &と*の関係は単純明白 let a = 123; // a: i32 let b = a; // b: i32 let p = &b; // p: &i32 let q = p; // q: &i32 let &r = &p; // r: &i32 let x = &q; // x: &&i32 let s = *x; // s: &i32 let c = *r; // c: i32 let y = &&c // y: &&i32 let z = y; // z: &&i32 let d = **z; // d: i32 720 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 09:35:44.42 ID:GD93l4al.net] ライブラリが他言語から使いにくいってのも謎だな 他言語からならC ABI一択なわけで、どの言語でライブラリ書こうが使い勝手は同じだと思うが 721 名前：デフォルトの名無しさん [2021/08/18(水) 09:48:19.81 ID:JVjfL7Fa.net] >>697 例えばPyO3でPythonからRust呼び出せるよ 722 名前：デフォルトの名無しさん [2021/08/18(水) 10:49:15.04 ID:NS5B/B7Q.net] >>672 自動的な参照外し(*を記載してないのに*適用)って、値を使うところで&Tや&&Tなどが使われたときにTの値になる、というルールだからそれも数学的でしょ。 あと&Tではない各種スマートポインタや自作の型を、*記載で参照外しする時も、Derefトレイト実装通りに行われるからこれも数学的。 723 名前：デフォルトの名無しさん [2021/08/18(水) 11:27:15.93 ID:k0LDI8WO.net] >>647氏が混乱したのもそこかもね 例えば let a = 99; let b = &a; assert_eq!(100, b + 1); assert_eq!(100, *b + 1); つまり値を使う所では参照のままではなく安全に*が自動適用 構造体のフィールドアクセスも struct Point {x: i32, y: i32} let p = Point {x: 19, y: 31}; let q = &p; assert_eq!(p.x, q.x); assert_eq!(p.y, (*q).y); つまりフィールドアクセスする所では参照のままではなく安全に*が自動適用 だからC言語などにある「q->y」という記法がRustには不要なので存在しない 724 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 11:41:08.71 ID:XfIyaV62.net] こじつけの自己レス自演が気持ち悪い これでバレないとおもってるんだからww お前も頑張って勉強中なの丸出しなのになぜそんなに上から目線で書きたがる？ 725 名前：デフォルトの名無しさん [2021/08/18(水) 12:12:05.22 ID:cmZsMbhP.net] >>710 assert_eq!(100, b + 1);　は通るけど assert_eq!(99, b);　はコンパイルエラーになるところがミソかな 726 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 12:12:56.84 ID:Lbl25gGI.net] 演算子も含めてメソッド呼出しのときの self の参照が調整されるのは言語コアの機能だけど 演算子の右辺で参照が剥がされるのは参照を受け取るバージョンのメソッドも用意されてるから という理解でいいんだよね？ 727 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 12:16:13.67 ID:UTiWVDvk.net] >>710 >assert_eq!(100, b + 1); `b + 1`のbは*が自動適用されてるわけじゃない 728 名前：デフォルトの名無しさん [2021/08/18(水) 12:52:27.85 ID:KGSse8GZ.net] そこはstd::ops::Addトレイトのimplがあるかどうか ただしi32と&i32に対してはあるけど&&i32に対してはない そのためさきほどの例だと let a = 99; let c = &&a; assert_eq!(100, **c + 1); // i32はそのままOK assert_eq!(100, *c + 1); // &i32は参照外してi32でOK assert_eq!(100, c + 1); // &&i32のAddトレイト定義はないからコンパイルエラー 729 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 13:56:40.85 ID:XmrgRQmj.net] 繰り返し間違った内容垂れ流すのいい加減やめれ 730 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 14:02:16.47 ID:NAGfODce.net] >>715で合ってるよ 731 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 14:42:37.07 ID:tdn9Bdbv.net] ご愁傷様 732 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 15:05:20.49 ID:PR0UGd3d.net] ご安全に* 733 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 19:37:59.33 ID:e8CK2aK/.net] 質問したようなのと近い流れになってて助かった (0..7).filter(|&x| x == 0); ↑これ通るから　↓こうしたら駄目だった。なんでなん？ let mut vec0 = vec![1, 2, 3, 4, 5, 6]; vec0.iter().filter(|&x| x == 1); そこで、様々テストしたら、↓の方法でコンパイルが通ることがわかった どのやり方が一般的なん？個人的には1か4かと思うんだけど。あと、2は+0することで型推論が働いてるのん？ vec0.iter().filter(|&x| *x == 1); //1 vec0.iter().filter(|&x| x + 0 == 1); //2 vec0.iter().filter(|&x| x == &1); //3 vec0.iter().filter(|&x| x.clone() == 1); //4 vec0.iter().filter(|x| **x == 1); //5 vec0.iter().filter(|x| *x == &1); //6 734 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 19:43:27.81 ID:4IMEZtM2.net] 全部結果まで含めて正しかった？ 735 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 19:48:58.01 ID:e8CK2aK/.net] ベクタの内容を↓にして let mut vec0 = vec![1, 2, 1, 4, 1, 6]; 1の数をcountするようにして表示させてみたけど、>>720の1〜6のやり方でどれもcountの数は同じだね 736 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 20:01:07.37 ID:e8CK2aK/.net] いいぞ！いいぞ！これも通るぞ！！ let mut test6 = vec0.iter().filter(|&&x| x == 1).count(); let mut test7 = vec0.iter().filter(|x| x == &&1).count(); let mut test8 = vec0.iter().filter(|x| *x + 0 == 1).count(); ヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノ 737 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 20:03:48.63 ID:gDWYR9GO.net] Bible終えるのにどれぐらい時間かかりましたか？ 738 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 20:30:38.07 ID:4eCzRIG7.net] >>720 739 名前： (0..7).filter(|&x| x == 0);と同等なのは let v = vec![1,2,3,4,5,6]; v.into_iter().filter(|&x| x==0); [] [ここ壊れてます] 740 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 20:47:56.15 ID:e8CK2aK/.net] >>725 うおー、まじか！ わかったありがとう。だからforループはちょっと違う挙動になるんだな 741 名前：デフォルトの名無しさん [2021/08/18(水) 21:38:07.08 ID:KGSse8GZ.net] 違いをわかりやすく示すと let vec0 = vec![1, 2, 3, 4, 5, 6]; assert_eq!(Some(&1), vec0.iter().next()); assert_eq!(Some(1), vec0.into_iter().next()); 742 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 21:41:22.71 ID:e8CK2aK/.net] ありがとうありがとう &TのイテレータとTのイテレータが別々になっているとはおもわなんだ 743 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 21:54:22.03 ID:8n3xPETQ.net] まだ慣れてないからideに言われるがままに直してるな、、 744 名前：デフォルトの名無しさん mailto:sage [2021/08/18(水) 22:38:04.93 ID:ErZJGc/A.net] イテレータ回りはこのスライドが良いと思ったけど多少基礎知識ないときついかもしれんな https://speakerdeck.com/optim/domination-of-the-rust-iterators 745 名前：デフォルトの名無しさん [2021/08/18(水) 23:13:44.45 ID:KGSse8GZ.net] >>728 そう考えるよりもムーブor借用と捉えるほうがいいかな vec0.into_iter()だとムーブになるから値そのものが次々と来る。しかしその後にvec0は使えない。 vec0.iter()だと借用になるから値への参照が次々と来る。その後もvec0は使える。 (&vec0).into_iter()でも借用になるから値への参照が次々と来る。その後もvec0は使える。 746 名前：デフォルトの名無しさん [2021/08/19(木) 02:05:43.13 ID:58T7qCMn.net] この2つは何が違うんですか？ 演算子? https://tourofrust.com/38_ja.html unwrap https://tourofrust.com/39_ja.html 747 名前：はちみつ餃子 mailto:sage [2021/08/19(木) 02:52:20.85 ID:z/GAGLjl.net] >>732 これは例がよくないな。 もう一段ほど関数呼出しを挟む構造になっていればより分かり易くなる気がする。 ? 演算子はエラーだったときにそのエラー値を返り値として return する。 つまりその例の場合は do_something_that_might_fail が エラー値を返したときは main から抜ける。 関数がエラーを出したときに上位にもエラーとして伝播させる機能。 unwrap は Result を剥がすが、エラー値だったときにはその場で panic する。 unwrap を書くというのは「エラー値が返されることはないことをプログラマとして保証する」 または「そのエラーに対して対処する方法はない、対処する気はない」という表明で、 assert 的な意味合いを含む。 エラーの対処を書くのが面倒だけど Result を剥がして型は合わせないといけない というときに雑に unwrap することはあるんだけど、 多少なりとも汎用的なライブラリにするなら (事前条件が正しい限り) panic が 起こるのは好ましくはないので使い方は慎重に。 748 名前：デフォルトの名無しさん [2021/08/19(木) 03:04:22.69 ID:KOsZ1Iay.net] >>732 ?演算子はほぼtry!マクロのsyntax sugar 言語自体に組み込んだ時にその適用範囲を広げた try!マクロとは見やすく省略して書くと Result型rに対してはtry!(r)がほぼmatch r { Ok(n) => n, Err(e) => return Err(e) }となる つまり?演算子はOption型やResult型の尻につけてNoneやErrの時にreturnする 一方でunwrapはpanicして死ぬ 749 名前：デフォルトの名無しさん [2021/08/19(木) 06:51:23.03 ID:3IqCrn23.net] ほぉ、なるへそ noneとかへの振る舞いの遅延行為としての?op ある関数を呼んだ関数自体でerrへの振る舞い決定すべきだと考えた場合は?opにする とすると?op含んだ関数のcallerはmatchとかのタイプ別振る舞い定義をちょっとやかましめ書く必要ありだな いまいちpanicの振る舞いが分からん spawned threadが内部でパニくった場合その娘、息子スレッド（スレッドの下層スレッド）とそのスレッド自体にのみunwindが適用されるんだよな？(´・ω・｀) 750 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 08:14:51.20 ID:1vsNr98D.net] 何でやねん(笑) 751 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 12:31:22.21 ID:vGJ7k9jZ.net] vec0.iter().filter(|&x| x == &1); これの数字に&つけて型同じにしたら通るってのが納得できないな〜 比較がプリミティブ型の変数同士だったら自動的に数値として扱って欲しい 752 名前：デフォルトの名無しさん [2021/08/19(木) 13:09:24.52 ID:5RRw/fpd.net] >>737 それは強い静的型付けのメリット 異なる型同士の==が通るのは困る といいたいところだけど PartialEqトレイト次第で異なる型でも==してくれる場合もある 文字列など でも整数は厳密でi32とi16ですら不許可 753 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 13:34:53.71 ID:vGJ7k9jZ.net] >>738 でも、上の例で vec0.iter().filter(|&x| x + 0 == 1); が通るのは+0したときに中身がプリミティブ型だから数値だけ取り出してくれてるんでそ？ 754 名前：デフォルトの名無しさん [2021/08/19(木) 13:41:52.67 ID:NIu45PdU.net] >>739 それはまた別で>>715 つまり足し算の実装 755 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 14:53:02.41 ID:qnkUxlpG.net] &i32 + i32 の計算ができるようAddトレイトで実装されていて、結果をi32で返すようになってるからエラーにならないってことでしょ？ 756 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 14:59:15.22 ID:OmSSsNQv.net] >>741 そのとぉーり！ 757 名前：デフォルトの名無しさん [2021/08/19(木) 15:34:51.11 ID:SriMwJau.net] >>741 ご丁寧にi32+i32 i32+&i32 &i32+i32 &i32+&i32の4種類をカバーしてくれてるね &&i32はサポートしていないため vec0.iter().filter(|x| x+1==2)はコンパイルエラー 758 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 16:37:43.70 ID:gHMNbMrQ.net] まず>>715の間違いを反省しようね >let a = 99; >let c = &&a; >assert_eq!(100, *c + 1); // &i32は参照外してi32でOK 759 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 16:44:47.80 ID:hQY8lbBV.net] >>744 それであってるぜ &i32+i32は左だけ参照を外してi32にして足し算する 760 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 17:44:32.43 ID:t/I60tUF.net] そりゃ当たり前だろw とことんダメなやつだな 761 名前：デフォルトの名無しさん [2021/08/19(木) 18:58:02.70 ID:58T7qCMn.net] >>733 >>734 丁寧に教えてくれて、ほんとありがとう 762 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 21:41:29.08 ID:vGJ7k9jZ.net] >>743 なるほど、なんかすべての挙動を把握しないとならないんだね でも、やっぱり「&1」が通用するのは納得いかない(´･ω･`) 763 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 22:05:30.35 ID:RF3Q0l8Y.net] >>748 基本的には正しく型を用いれば済む &i32は数値ではなく数値への参照にすぎない *付けなくても済む便宜の恩恵を受けるのはよいけどそれを理解したうえでしているかどうかの違い 764 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 22:29:20.97 ID:c562wt5h.net] String と &str が == で比較できるなら i32 と &i32 も比較できて良い気はする 単に impl がないだけだから pull req 送ったら取り込んで貰えるのでは 765 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 22:55:59.39 ID:vGJ7k9jZ.net] もう純粋に&1て、1の参照じゃんね その意味がわからんし、存在意義がわからん 変数同士ならわかるけど、定数的に書いてるんだったらもうプリミティブ型だったら 中身で判断してくれよヽ(`Д´)ﾉｳﾜｧｧｧﾝ 766 名前：デフォルトの名無しさん [2021/08/19(木) 23:28:13.13 ID:2mmZi2HD.net] >>750 今もi32と&i32の組み合わせ4通り定義 そこへ&&i32が加わると9通り定義 そこまでする意義は？ >>751 だからx==&1ではなくて素直に*x==1と書こう 767 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 23:48:19.67 ID:k/U3ouxt.net] >>751 プリミティブのwrapper crateを作って自分の好きなように定義すれば万事解決 768 名前：デフォルトの名無しさん mailto:sage [2021/08/19(木) 23:58:39.37 ID:A1SUdzrU ] [ここ壊れてます] 769 名前：.net mailto: そういや&1みたいなのって実際に使う場面あるの？ [] [ここ壊れてます] 770 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 00:03:22.90 ID:o+L+NM8T.net] 推奨する方法をやりやすく、推奨しない方法をやりにくく Rustは他の言語に比べると特に後者についてよく考えられてる 771 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 00:07:53.98 ID:iQK+FWFq.net] >>754 postgresクレートのquery()でparamsに数字を書きたいときとか pub fn query<T>(&mut self, query: &T, params: &[&(dyn ToSql + Sync)]) -> Result<Vec<Row>, Error> where T: ?Sized + ToStatement 772 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 01:09:30.92 ID:W7hoDzmL.net] >>752 *x == 1 と書けというのは分かるんだけど impl PartialEq<String> for &str や impl Add<&i32> for i32 があるのに impl PartialEq<&i32> for i32がないのは一貫性がないように思う なんで実装されていないのだろうか 773 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 01:11:40.00 ID:W7hoDzmL.net] >>757 自己解決 RFC1332で議論されていた 774 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 01:12:10.07 ID:hEbF/PXF.net] rubyもpythonも見よう見まねで書けるんだけどなー javaなんてC++とほとんど同じだから半日もあればマスターできる でもrustだけは勉強しないと無理っぽい 難しいよ 775 名前：デフォルトの名無しさん [2021/08/20(金) 01:34:49.41 ID:qcewwL/9.net] >>757 実は整数と文字列ではそこの逆転現象が起きていて Stringと&strの等号比較はOK assert!("xyz".to_string() == "xyz") しかしStringをmatch文でアームに&strだとコンパイル型エラーでNG // assert!(match "xyz".to_string() { "xyz" => true, _ => false, }); &i32とi32の等号比較はコンパイル型エラーでNG // assert!(&123 == 123); しかし&i32をmatch文でアームにi32だと比較OK assert!(match &123 { 123 => true, _ => false, }); 776 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 01:38:48.16 ID:omEK/Sui.net] オブジェクトの同一性 (メモリ上の同一の場所に配置されている) を判定したいときって 参照を == で比較しても駄目ですよね？ ポインタを取り出すのも恰好が悪いように思うんですが、 なんか定番の方法ってあります？ 777 名前：デフォルトの名無しさん [2021/08/20(金) 01:44:35.28 ID:qcewwL/9.net] >>754 消費(ムーブ)せずに参照で済ませるためにiter()を使うと当然 &1 が出てくる let vec0 = vec![1, 2, 3, 4, 5, 6]; assert_eq!(Some(&1), vec0.iter().next()); assert_eq!(Some(1), vec0.into_iter().next()); これはVecだから消費するinto_iter()が使えば 1 に出来るけど スライスだと消費という概念がないから必ず &1 が出てきてしまう 778 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 01:55:55.02 ID:jENR+46K.net] >>761 Rustは所有権があるから同一メモリを指すのは所有権を持つものへの参照同士かな つまりコード上明白であり比較する必要性がないことに？ 779 名前：デフォルトの名無しさん [2021/08/20(金) 02:30:09.57 ID:qcewwL/9.net] こういうことかな 複数の参照もmut参照も生ポインタも当然すべて同じアドレスを指している let mut i = 123; let pi1 = &i; let pi2 = &i; println!("{:p}", pi1); // 0x7fffebf915a4 println!("{:p}", pi2); // 0x7fffebf915a4 let pi3 = &mut i; println!("{:p}", pi3); // 0x7fffebf915a4 let rpi3r = pi3 as *mut i32; // 生ポインタ println!("{:p}", rpi3); // 0x7fffebf915a4 生ポインタを使って書き換えると元の変数が書き換わるので確かにこれは変数の格納アドレス unsafe { println!("{}", *rpi3); // 123 *rpi3 = 456; } println!("{}", i); // 456 780 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 02:32:13.12 ID:0J8On0UY.net] ptr::eqで 781 名前：デフォルトの名無しさん [2021/08/20(金) 10:16:46.67 ID:Z3M3k8Ob.net] メンテナンス性最悪の自己満足オナニー言語 782 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 11:41:07.99 ID:0Iuc7w1s.net] >>766 それは逆 メンテナンス性は最も優れているプログラミング言語の一つ 783 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 13:42:55.60 ID:ZqTwz4dI.net] ポインタ関連の問題が所有権と参照で絶対に発生しないってのはデカイよね 784 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 13:59:09.33 ID:lR6AxyIv.net] 将来の苦痛を先に解消できるのが良いのにな、不具合も絞り込みやすい メンテナンス性悪いってどの辺言ってんのか聞いてみたい 785 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 14:18:54.33 ID:nkJxp5PO.net] 一年ぶりに触るソースを大規模改修しても、コンパイル通せばほぼ動く安心感ある 他言語（特に動的型言語）だと相当テストを作り込まない限り、このメンテナンス性は得られない印象 786 名前：デフォルトの名無しさん [2021/08/20(金) 14:28:37.40 ID:y1HLeTwS.net] データ設計を少し考えさせられることによって メモリ安全性を得ただけでなく見通しも良くなったｗ 787 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 15:07:52.58 ID:No4kn/Ah.net] 潜在的にバグの原因となる変数の扱いすると コンパイラが怒るのは安心できる 788 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 15:24:51.42 ID:W7hoDzmL.net] >>768 絶対に発生しないは言い過ぎ 789 名前：デフォルトの名無しさん [2021/08/20(金) 15:31:54.88 ID:sJeXN42B.net] 繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。。 そして文字列が複数あったり、更にそれをマクロにされると、それで書き直しが必要だったり 多くの言語でも初心者と上級者で当然、コードの美麗さに違いが出るが余りにも差があり過ぎ たった「一年ぶり」でコンパイルが通らない言語なんてあるだろうけど、そんな話じゃない 790 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 16:06:16.17 ID:c/gVhnyt.net] イテレータなんてどの言語にもあるし困るようなことか？ 無理やり導入で汚い言語よりもRustは綺麗に洗練されていて書きやすい 791 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 16:12:21.41 ID:BL1Grv4c.net] 同じようなことなのに人によって書き方が全然違うからクソって言いたいんじゃないの？ 792 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 17:10:02.79 ID:H8grjHSU.net] 何が何故問題なのか説明できないイチャモンなんかほっとけ 793 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 20:06:41.30 ID:W7hoDzmL.net] 文字列が複数種類あることが嬉しい人のための言語 嬉しくない人は別の言語を使うべき 794 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 20:28:27.92 ID:TearUC8B.net] >>778 例えばいわゆるスクリプト言語などはいずれもRustのString型相当のものしかないため非効率でメモリ食い散らかす状態になっていますね Rustはそれに加えて部分を指し示すだけの文字列スライス&str型を持っているので無駄なアロケーションを防いで効率の良いコードを書けるようになっていますね 795 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 21:05:31.52 ID:ma1oO0u7.net] >>774 > 繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。 あなたはちょっと無知すぎます。 まず高階関数とも言われるmap()やfilter()等を用いるにはイテレータが必須ですから同じことを指しています。 どちらかを選ぶようなものではありません。 次にRustのforループもイテレータ必須で内部でイテレータを作ってforループを回していますから同じことです。 forループ方式と高階関数方式の2種類で書けてしまうじゃないか！と言いたいのでしょうが、これは他のプログラミング言語でも同じで2種類あります。 796 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 21:07:42.14 ID:EDzGRqES.net] 内包表記なる書き方がある言語もあるらしいねｗ 797 名前：デフォルトの名無しさん [2021/08/20(金) 21:38:29.08 ID:6XnQ3Oqv.net] 繰り返しでiter()を使ったりinto_iter()を使ったりと複数のやり方があるのはおかしいとの御指摘だが into_iter()は値のイテレータ iter()は参照のイテレータ 同じものに対して適用しても別のイテレータが得られる 798 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 21:47:24.73 ID:pKmgqbo7.net] 少し前までは荒らし以外は結構いいスレだったが 近頃はC++スレでダベってた暇人たちが引っ越して来ちゃってゴミスレ化しつつあるね 799 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 22:24:24.81 ID:ZqTwz4dI.net] >>782 これ、同じメソッドにするのではなくて、イテレータにするのはiter()で共通にして、 参照する場合には、別のメソッドにしたほうがいいんじゃないのかなと思う 例えば iter()　←　値 iter().ref()　←　参照 とか 800 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 22:50:20.88 ID:hEbF/PXF.net] なんで配列にイテレータないんや！ 配列を使うな！ vecを使えということなのか そういえばC++でもvector使えとか言われてたな もっと配列にも愛を！ ところでvecより配列の方がうれしいことってある？ 実は配列いらない子なんじゃないかと思い始めた 801 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 23:02:42.83 ID:Dd/EBaxX.net] >>784 それはiterのシグネチャがメソッドチェーンするかどうかで変わってしまうから 今のRustの型システムでは表現不能だと思う プログラマ視点でも、後続する関数呼び出しがその手前に影響するってのはかなりわかりにくいのでは？ 802 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 23:22:41.88 ID:tipMusVW.net] >>785 スタックとかヒープとかアロケーションとか気にならない用途ならRust使わなくてもいいと思うの 803 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 23:47:01.90 ID:Omw4vOgK.net] >>786 moveをデフォルトにするのは無理だけど iter()は参照でiter().into()で値ならCow的なのでなんとかなる気がする 804 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 23:47:19.51 ID:iQK+FWFq.net] >>785 > Rust 1.53からは配列型に対して直接IntoIteratorトレイトが実装されるようになり、配列をそのままループに使うことが出来るようになりました。 https://tech-blog.optim.co.jp/entry/2021/06/18/080000 805 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 23:54:51.56 ID:hEbF/PXF.net] >>787 いやいや、もちろん配列との比較なんだから、アロケーションの発生しない処理の話だよ スタックを気にするなら、むしろヒープに置いた方がいいし (キャッシュミスヒットの話じゃなくて、スタックオーバーフローの話ね) 806 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 23:55:03.84 ID:Dd/EBaxX.net] >>788 それだとinto_iterとは意味変わっちゃってるのでは intoで元のコレクションのコピーが作られて、それをイテレートするってことでしょ？ コピーを作らず所有権を奪って値をイテレートする方法がなくなってしまう 807 名前：デフォルトの名無しさん mailto:sage [2021/08/20(金) 23:56:59.11 ID:hEbF/PXF.net] >>789 おお！　知らなかった。 ってかめっちゃ最近じゃん！ 追いかけるの大変だな 808 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 01:58:33.16 ID:kcBD0DB/.net] >>784 iter().cloned() とか使えば良いのでは 809 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 05:48:08.14 ID:lXSuJ2vU.net] hoge.iter()だと参照でhoge.iter().fuga()だとhogeの所有権ぶんどる、みたいなのは無理な気がする 810 名前：デフォルトの名無しさん [2021/08/21(土) 06:24:06.23 ID:kvS3AY0X.net] >>790 Vecは可変長なので必ずヒープからアロケーションが発生します 一方で配列は必ず固定長でスタックに置かれます >>784 (&vec0).into_iter()はvec0.iter()となるので into_iter()だけにすることも出来なくはないと思いますが 書き方が面倒なので簡潔なiter()と共存してるのだと思います 811 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 09:34:58.66 ID:v7gED8U+.net] >>791 Cow使えばできるという話じゃないよ lazyに所有権を取得するような機能を持った型を追加すれば 今の型システムでも表現できないってことはないんじゃないかって話 そういう型を追加することを型システムの変更と言うのであれば 今の型システムでは表現できないてのに同意するよ 812 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 09:43:26.29 ID:KTz5aeQ/.net] >>795 アロケーションが発生するのは伸長するときだけでしょ 伸長するような用途だったら、そもそも配列使えないし >一方で配列は必ず固定長でスタックに置かれます だめじゃん。スタックオーバーフロー考慮するならvecの方がいいじゃん まあ、自分も組み込み以外でスタックフレームのサイズなんて考慮したことないけど 813 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 09:50:40.59 ID:KTz5aeQ/.net] >>795 ちなみにスタックにあることによってL2キャッシュに載りやすいだろ！ という意見ならそれは同意する。サイズが小さければね。 814 名前：デフォルトの名無しさん [2021/08/21(土) 10:08:08.47 ID:/0ZvMIRv.net] >>797 > アロケーションが発生するのは伸長するときだけでしょ いいえ。 Vecの実体は必ずヒープにアロケーションされます。 Vec自体は(指定しなければ)スタック上で、ヒープへのポインタや長さなどで構成されて固定長です。 Stringも内部はVec<u8>なので同様です。 815 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 10:12:53.88 ID:KTz5aeQ/.net] >>799 ああ、アロケーションじゃなくてヒープにってところを問題視してる？ ガベージコレクションの発生を懸念してる？ 816 名前：デフォルトの名無しさん [2021/08/21(土) 10:22:22.66 ID:HwKH2mPW.net] >>800 Rustではガベージコレクションは起きない しかしスタック上かヒープ上かの区別は重要 スタック上のデータはその関数を終える時に消滅する 817 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 10:31:43.28 ID:KTz5aeQ/.net] >>801 >Rustではガベージコレクションは起きない ヒープを使ってるんだから起きないわけないだろ ＞スタック上のデータはその関数を終える時に消滅する Vecの中身だって関数を終えるときに解放されるでしょ されないんだっけ？ そもそもの話は配列を使ってるところをVecにしても問題なくね？ってことなんだけど どこが問題になるかの例を示してもらえたら、わかりやすい 818 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 10:58:14.92 ID:Hi//C77Q.net] rustにはガベージコレクションがないんだぜ・・・ 819 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 11:04:35.75 ID:eqU3IJp1.net] デストラクタ的な機構で後始末するのはガベージコレクションとは普通言わない 820 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 11:09:11.24 ID:JLDZmydZ.net] Cでもひーぷをつかうとがべーじこれくしょんがおきるの？ 821 名前：デフォルトの名無しさん [2021/08/21(土) 11:11:34.22 ID:6mCMrQuL.net] ヒープへのメモリアロケーションはコストが高いから避けたいんでしょ 822 名前：デフォルトの名無しさん [2021/08/21(土) 11:25:28.41 ID:ozkLLafu.net] >>802 RustにGCはない Vecの中身(配列相当部分)はスタック上ではなくヒープ上なので関数を終えるときに解放されない Vec自体が消える時に解放される Vec自体(ポインタと長さなど)はスタック上にあれば関数を終える時に消える もちろんVec自体を関数の返り値として返すことは出来る 受け取った上位の関数でVecの中身を使える 例えば fn main() { 　let mut v: Vec<i32> = make_i32_vec_from_args(); 　v.push(999); 　println!("{:?}", v); } fn make_i32_vec_from_args() -> Vec<i32> { 　let mut v = Vec::new(); 　std::env::args().skip(1).map(|s| s.parse::<i32>().unwrap()).for_each(|n| v.push(n)); 　v } $ cargo run 111 222 333 [111, 222, 333, 999] 823 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 11:42:53.96 ID:3jqa2oM2.net] そういや何でalloca()無いの？ 824 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 12:23:12.36 ID:kcBD0DB/.net] >>795 Box<[T; N]> のように配列がヒープに置かれる場合もある 825 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 12:35:23.13 ID:5zDPvhJy.net] >>809 それはBoxだからであって、そんなこと言い出したら整数だってヒープに置かれうる しかし普通に「整数型はスタックに置かれる」と言われる時は、Boxを使わない場合を意味している Boxを使えばヒープに置かれるのは自明だからだ したがって、整数や配列やVecの管理データ部分はそのままだとスタックに置かれるがVecのデータ実体は常にヒープに置かれる、で良い 826 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 13:25:00.39 ID:KTz5aeQ/.net] うーん、なんだかなー みんなヒープのことを無限にバイトを吐き出す魔法の箱かなんかだと思ってない？ >>805 >Cでもひーぷをつかうとがべーじこれくしょんがおきるの？ 当然 Cのmalloc/freeやC++のnew/deleteでもガベージコレクションは発生する wikipediaの「ヒープ領域」がよくまとってるよ いくつかの理由からfree/deleteのガベージコレクションはJavaやC#のガベージコレクションよりも超高速だ それでも、組み込みの世界ではガベージコレクションのせいでリアルタイム性が失われることを嫌がって、 ヒープを使わなかったりする じゃあ、組み込みでは動的なメモリをどうするかっていうと、リンクドリストのノードをメモリブロックに 見立てて、メモリ管理システムにしたりする これだと取得も解放も定数時間のコストだからね >>807 すまん、例をみてますます配列なくても困らない気がしてきた 配列でできて、Vecにできないことはないの？ 827 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 13:35:03.05 ID:+9L1DmAB.net] >>811 Rustにはガベージコレクションはありません おっしゃる通りヒープからの取得も解放も定数時間のコストで行なわれ更にガベージが溜まることはありません Rustでは生存期間や所有権に貸し借りが明白になっているため、使用中のものが解放されたり、解放済みが使われたり、使用済みが解放されなかったりは起きません 828 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 13:50:09.86 ID:KTz5aeQ/.net] >>812 >ヒープからの取得も解放も定数時間のコストで行なわれ これってどういう原理？　本当に定数ならそれもうヒープじゃないんじゃ ヒープツリーを辿る処理も未使用ノードを結合する処理も定数時間って ありえないと思うんだけど 829 名前：デフォルトの名無しさん [2021/08/21(土) 14:16:15.10 ID:G8x/1s0B.net] もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも そのためRustにガベージコレクションがないことを理解できていないような感じ？ 830 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 14:22:08.01 ID:KTz5aeQ/.net] 調べた ・rustのヒープはフリーリストアロケータじゃない （サイズごとのメモリスラブをさらに分割して使う） ・取得・解放は定数時間じゃない (メモリスラブ全体が未使用になったときに、デフラグして別サイズのスラブとして利用可能になる) →これ実質ガベージコレクション処理じゃん ・当然デフラグは発生するが、大して問題にならない →そうだろうね。C++でさえアロケータ書いたことない ・問題になるならアロケータを自作することも可能(デフォルトはjemalloc) だそうだ。 ヒープはヒープ構造じゃないのか…… 831 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 14:36:21.13 ID:KTz5aeQ/.net] >>814 >もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも freeの中にもガベージコレクション処理があるんだよという話 javaと違ってマーク＆スイープ処理いらないから早いけどね >そのためRustにガベージコレクションがないことを理解できていないような感じ？ そんなことはわかってる 今は処理コストの話をしてる サイズが変わらないVecと配列(配列なのでもちろん固定長)でそこまで優位の差があるのかと訊いた そこでVecはヒープを使う(からダメだ)という答えが返ってきたので、 ヒープを使うとなぜダメなんだ？　ガベージコレクションのオーバーヘッドを気にしてるのか？と そうするとrustはガベージコレクションありませんと言われた じゃあ、結局のところヒープを使うとなぜダメなんだ？ 832 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 14:43:58.08 ID:3jqa2oM2.net] 勝手に定義した「ガベージコレクション」なんか議論するだけ時間の無駄 833 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 14:48:02.99 ID:HlQuVij0.net] >>816 あなたが完全に間違っている それを世間ではガベージコレクションとは呼ばない 834 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 14:50:34.09 ID:KTz5aeQ/.net] >>818 辞書が絶対とは言いたくないがwikipediaの「ヒープ領域」見て 835 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 14:52:48.65 ID:Hi//C77Q.net] 自分でfreeしたものをGCと呼ぶとは強者が現れたな 836 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 14:53:06.41 ID:O7+p4qIy.net] それこそwikipediaの「ガベージコレクション」見てもらった方がいいのでは。 837 名前：デフォルトの名無しさん [2021/08/21(土) 14:53:37.02 ID:6mCMrQuL.net] もうジェマロクはデフォルトじゃないよ 838 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 14:58:27.12 ID:Hi//C77Q.net] そういやこんな記事があったよ 実装言語を「Go」から「Rust」に変更、ゲーマー向けチャットアプリ「Discord」の課題とは ttps://atmarkit.itmedia.co.jp/ait/articles/2002/10/news038.html > 平均すれば高速に動作していたものの、数分ごとに平均応答時間が急に大きくなり、 > ユーザーエクスペリエンスを損なっていた。調査したところ、 > これはGoの中核機能であるメモリモデルとガベージコレクタ（GC）に起因することが分かった。 > Rustではガベージコレクションが不要だ。 > 同社がRead StatesサービスをRustで実装しようと考えたのはこれが理由だ。 > Rustを使えば、Goで実装した場合に生じた平均応答時間の急増は見られないだろう。 839 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 15:02:21.85 ID:KTz5aeQ/.net] >>820 だから、ここではコストの話をしてるんだって言ってんのに >>821 見た。もちろん知ってる。 本題からずれてる。自動解放とかデフラグの定義の話がしたいんじゃない 配列とVecのことが知りたいんだって なんだってこう話を逸らすんだ？ 840 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 15:02:56.01 ID:watXYiN6.net] >>819 https://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:%E3%83%92%E3%83%BC%E3%83%97%E9%A0%98%E5%9F%9F > 7月15日（土）12:22の版で記述いただいた内容のうち、「ガベージコレクション」という部分だけ誤りと思われるので、7月19日（水）02:32の版で消させていただきました せやな。 841 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 15:10:24.32 ID:hSZ/tOwO.net] >>824 まずはプログラミング言語におけるガベージコレクションとは何かを理解して 次にRustではそのガベージコレクションがないことを理解して その上で何を質問したいのかを整理してはいかがでしょうか？ それを終えてからでないとあなただけ用語の定義が異なったままでは話が進みません 842 名前：デフォルトの名無しさん [2021/08/21(土) 15:10:57.04 ID:IZ1Oj5x4.net] ガベコレは普通javaとかpyのコンパイラやらインタプリタがreference counterをオブジェクトに勝手に付随させる事を想定するけどな Vec arr処理コストの違いに関してはbuffer使わないんだからarrayの方が基本的には糞みたいに早いと思うがな そこらosとかによって最適化図られるからオブジェクト生成のとき以外は決定的な違いあんまなさそうだが 要素数をコンパイルタイムに決定(これのアルゴにもよるが)出来るなら普通はシンプル配列の方が速いよね goはparallel threadingみたいな部分で変なgc実装してて大量に独立の計算量ハード問題導入するからねそこらへんがドイヒーなんだろうな 俺は好きだけど(´・ω・｀) 843 名前：デフォルトの名無しさん [2021/08/21(土) 16:18:04.16 ID:iwjgeVKb.net] >>824 何度も説明されている通り 配列は固定長なのでデータ管理部分はなく配列は通常スタック上 Vecは可変長なのでデータ管理部分がありそれは通常スタック上そして配列相当部分は常にヒープ上 844 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 16:29:59.01 ID:0b1Dm8dh.net] コンパクションとガベージコレクションの区別がついてない 世の中のガベージコレクターがコンパクションもやってるからといって コンパクションのみを指してガベージコレクションとは呼ばない 845 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 16:33:27.85 ID:Ay6lvOn8.net] ふりだしに戻る >>787 846 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 16:37:39.49 ID:KTz5aeQ/.net] >>828 それの何が問題？ stringの実装はヒープだけど問題ないよね？ こういう使い方をすると配列より100倍くらい遅いとか、メモリリークするからVec止めて配列使えとか そういう注意点ある？ もちろんループの中でVec::newするとオーバーヘッドでかいとか、 そういうわざとらしいのはなしにして あえていうなら初期化の記述量がちょっと増える、とか？ 847 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 16:59:15.86 ID:dJkGQ7Qm.net] >>831 誰も何も問題にしていませんよ あなたが勘違いをして勝手な何かを問題にしているだけ StringはVecにstructの皮を被せただけなので状況は同じ 848 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 17:06:03.36 ID:Hi//C77Q.net] >>829 HDDの頃はよく使ってたHDD最適化と容量を増やすみたいなソフトを思い出した HDDのデフラグ　→　メモリコンパクション HDDにある不要なキャッシュの削除　→　ガベージコレクション こんな感じに似てるな 849 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 17:16:16.64 ID:eqU3IJp1.net] ヒープがヒープ構造じゃないのかとか言ってるから本当に何も知らなかったのだろう オレオレ用語使われると混乱するからとりあえずmalloc動画くらいみて勉強してきてほしい 850 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 17:26:30.08 ID:KTz5aeQ/.net] >>834 そこ話の本筋じゃないんだよなー Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー 851 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 17:30:07.73 ID:pF+sRbnf.net] >>835 ヒープ使ってるからダメ、なんて誰も言っていない 全ては君の勘違い 852 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 17:31:33.62 ID:KTz5aeQ/.net] >>836 そうなの？　じゃあ結論として配列はVecに置き換えても問題ないってこと？ 853 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 17:52:04.92 ID:eqU3IJp1.net] Vecは固定長配列(型[u8; 32]とかで表されるやつ)を置き換える用途としては使えないが, 逆に言えばそれだけ 854 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 18:26:53.45 ID:Hi//C77Q.net] むしろ配列なんてクレート使わないとコンパイル時点で数値が決まってないと使えないから ほとんど出番がないんだから、どこに悩む必要があるというのか 855 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 18:30:22.30 ID:AgJApIsV.net] >>835 ＞Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー あなたの妄想ではないですか？ スレを読みましたが、 Vecはヒープ使ってるからダメと言われた書き込みが見当たりません。 856 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 18:31:04.95 ID:3jqa2oM2.net] ヒープは悪であるということをハッキリと言う 857 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 18:41:19.82 ID:tswurJ+7.net] Linux のデフォルトではスタックの大きさは 8 メガが上限じゃなかったっけ？ (Windows だともっと小さかったはず) 大きさが固定 (コンパイル時に確定する) でかつ十分に小さく寿命が短いなら配列をスタックにおく のは性能的に有利 (確保と解放のコストが小さい) だが、大きさを見積もれないときにスタックに置くと スタックが足りないときにどうにもできないで即死するしかない。 大きさのわからない配列はスタックに置くべきではないというのが世の常識というもの。 少なくとも高レイヤのアプリケーションでは。 858 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 20:16:15.20 ID:3jqa2oM2.net] 仮想メモリなんだからスタック8GBに設定すればいいんじゃないの？ 859 名前：デフォルトの名無しさん [2021/08/21(土) 20:43:23.20 ID:7GAoG1Iq.net] Rustのメモリ安全性はボローチェッカーによって担保されているが、 Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、 GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ 限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？ Nimの実験的特徴 著者： アンドレアス・ルンプ バージョン： 1.5.1 nim-lang.github.io/Nim/manual_experimental.html Nimは限りなく抑え込まれたタイプ量で高い生産 860 名前：性とPythonのような高い可読性を実現し ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます [] [ここ壊れてます] 861 名前：デフォルトの名無しさん [2021/08/21(土) 20:47:51.35 ID:6mCMrQuL.net] Nimは知らんがパイソンが読みやすいなんて 862 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 20:53:42.26 ID:Z4f8T8IW.net] pythonが特別読みやすいとは思わんが、pythonで読みづらいコード書くやつが 何で実装しても読みやすいものを書くことはないだろう。 863 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 20:55:25.62 ID:6DBrqemS.net] >>844 Pythonはたまたま外部ライブラリ充実などで普及していますが、あまりよろしくない言語です。 そのためPythonで開発したいという人はいないです。 なので「Pythonのような高い可読性を実現している」と宣伝されても逆効果。 864 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 20:58:33.68 ID:O7+p4qIy.net] >>844の人は関係ないスレに迷惑かけて、nimユーザーのイメージダウンが目的なんだろうか。 865 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 21:35:33.43 ID:PyG7lKVy.net] 積極的にPython使おうとは思わんなぁ。インタプリタ系はRuby使っているわ Luaも結構良い感じだと思う 866 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 21:54:02.20 ID:tswurJ+7.net] うん。 プログラマは Python をそんなに気に入ってない場合は多いと思う。 ただ現代ではプログラミングするのはプログラマとは限らない。 Python は元々はコンポーネントを組み合わせる、いわゆるグルー言語として設計されていて、 エンドユーザ向けの性質を持っている。 BASIC 系と似た立場かな。 このくらいに制限されていたほうがかえって使いやすいという場合は確かにある。 必要なコンポーネントが出そろっている状況で上位のロジックを組み立てる分には Python も便利なこともあるにせよ、言語としての出来はそんなに良くない。 867 名前：デフォルトの名無しさん [2021/08/21(土) 21:59:07.63 ID:7GAoG1Iq.net] >>845 >Nimは知らんがパイソンが読みやすいなんて Pythonは構文にインデントを組み込むことによってざっと眺めた時に人間が読みやすい 一般的には上記の事をPythonは高い可読性があると表現されています この事は「Pythonは可読性の高い言語」ググれば約 265,000 件出てきます 他の言語と可読性は同じだろって意見の人もいますが少数派ですね 868 名前：ハノン mailto:sage [2021/08/21(土) 22:21:31.89 .net] >>851 https://mevius.5ch.net/test/read.cgi/tech/1587276362/963 「javascriptは可読性の高い言語」で検索すると約 334,000 件 869 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 22:31:37.65 ID:7PPLxZL+.net] 元の文脈的に nimも構文にインデントを組み込んでるからpythonが出てきただけでそういう議論がしたいんじゃないと思う 870 名前：デフォルトの名無しさん [2021/08/21(土) 22:36:10.82 ID:7GAoG1Iq.net] >>852 >「javascriptは可読性の高い言語」で検索すると約 334,000 件 単に検索件数が多いだけで、上位10件の表示内容を読んでも 「javascriptは可読性の高い言語」と言う内容のページは1つも見つかりません 対して「Pythonは可読性の高い言語」は上位10件の内5件見つかりました 871 名前：デフォルトの名無しさん [2021/08/21(土) 22:41:14.03 ID:7GAoG1Iq.net] >>853 おっしゃる通りです(/ω＼) 872 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 22:56:47.50 ID:lXSuJ2vU.net] ただのコピペ荒らし まったくRustもNimも関係ないスレでも見るし 873 名前：デフォルトの名無しさん [2021/08/21(土) 23:00:47.35 ID:YSvCkW+D.net] Rust Tourだけやっていても作業の流れが身につかなさそうなので、写経を始めました そこでまず出くわしたのがTokioのバージョンの壁で、バージョンによって動いたり動かなかったり差がありました クレートの無難なバージョンがどれか、クレート同士の無難な食い合わせはどれか、など、どうやって知れば良いのですか？ 874 名前：デフォルトの名無しさん [2021/08/21(土) 23:07:06.11 ID:7GAoG1Iq.net] >>857 Nimの写経を始めましょう 875 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 23:07:52.34 ID:kcBD0DB/.net] 写経なら写し元と同じバージョンにそろえるのがよいのでは 876 名前：デフォルトの名無しさん [2021/08/21(土) 23:24:51.23 ID:7GAoG1Iq.net] >>859 >写経なら写し元と同じバージョンにそろえるのがよいのでは Nimのバージョン 1.5.1を写経しましょう Nimの実験的特徴 著者： アンドレアス・ルンプ バージョン： 1.5.1 nim-lang.github.io/Nim/manual_experimental.html 877 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 23:48:46.37 ID:PyG7lKVy.net] 組み込み系ではMicroPythonが流行っているらしいが全く魅力を感じないｗ 878 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 23:53:13.51 ID:+zMEbJ+6.net] Nimを調べてみたのだが Rustよりも高機能な点を見つけられなかった もし有るならば書いてください 無ければ去ってください 879 名前：デフォルトの名無しさん [2021/08/22(日) 02:15:33.57 ID:0Cz6ueFz.net] >>862 >Nimを調べてみたのだがRustよりも高機能な点を見つけられなかった >もし有るならば書いてください >無ければ去ってください そんな寂しい事言わないでかまってよ〜(´;︵;`) 行末のセミコロンが必要ない タイプ数がもりもり減ります。 Rust にはもちろん必要です。 main が要らない スクリプト言語感覚でいきなりコードを書けます。 Rust は main が必要です。 >Nimキチガイ いつもみんなによく言われます いや〜照れますね〜ｖ（=＾0＾=）ｖ 880 名前：デフォルトの名無しさん [2021/08/22(日) 02:16:39.23 ID:KEfgBimj.net] >>863 nimのスレ立ててそっちでやってよ 881 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 02:32:40.46 ID:w5XnK8W7.net] >>863 あなたは知恵遅れか何か？ Rustより高機能な点を問われているのに、セミコロンが必要ないとかどうでもいい話しかできないの？ 答えられないならここから出ていきなさい。 882 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 02:33:23.15 ID:j+Q/a+4n.net] 構うな さっさとNG 883 名前：デフォルトの名無しさん [2021/08/22(日) 02:35:27.65 ID:0Cz6ueFz.net] >>863 >nimのスレ立ててそっちでやってよ そんな寂しい事言わないでかまってよ〜(´;︵;`) Nim は標準出力への文字列出力が楽 Nim では echo で改行付きの出力ができます。shell と同じですね。通常は改行付きで出力することの方が多いでしょ。 Nim はしょっちゅうやることは簡単にできるようになっています。 そんな Nim の echo は可変引数で値を受け取り型が何なんだろうとお構いなしに出力できます。 let n = 10 let str = "HOGE" echo "Number: ", n, " String: ", str 一方 Rust は let n = 10; let str = "HOGE"; println!("Number: {} String: {}", n, str); なんかよく判らんマクロでいちいちびっくりさせなきゃいけないです。よく使うものが冗長だとゲンナリします。 変数を直接ぶち込むことも出来ませんしね。 let n = 10 echo n 普通出来るでしょこんなもん・・・。ところが Rust は出来ない。 let n = 10; println!(n); <- エラー println!("{}", n); <- 毎度これを書かされる うざいっす。 884 名前：デフォルトの名無しさん [2021/08/22(日) 02:38:26.87 ID:0Cz6ueFz.net] >>865 そんな寂しい事言わないでかまってよ〜(´;︵;`) NimはC の関数を気軽に持ってくる たった一行足すだけで C の関数を使うことが出来るようになります。 proc printf*(format: cstring) {.header: "<stdio.h>", importc: "printf", varargs.} let n = 10 let str = "HOGE" printf "Number: %d String: %s\n", n, str どうですこれ？C の資産を気軽に使うことができるんです。SWIG 等の鬱陶しいラッパーを使うこと無くです。 Rust の場合はご多分にもれずラッパー行きで超絶面倒くさいです。比較用に書きたいんですが結構な文章量になるのでやめます。 885 名前：デフォルトの名無しさん [2021/08/22(日) 02:44:19.98 ID:0Cz6ueFz.net] >>866 そんな寂しい事言わないでかまってよ〜(´;︵;`) Nimはmut mut しなくて良い Rust はまともな変数を使おうとすると mut mut しないといけません。デフォルトだと再代入できませんから。 普通再代入しまくりますよね？定数ライクに使いた� 886 名前：｢機会なんて殆どないですよね？なのに mut を毎度書かされます。 let n:int = 10 let mut m: int = 10 Nim ならこうですよ。 let n = 10 # immutable var m = 10 # mutable 素敵。 [] [ここ壊れてます] 887 名前：デフォルトの名無しさん [2021/08/22(日) 02:55:06.51 ID:0Cz6ueFz.net] >>862 Nim所有者・借用なんてもんでイライラしない 　Rust には C のポインタが可愛く見えるレベルで高くそびえ立つ鉄壁の初心者ガード、悪夢の"所有者・借用"の概念が存在します。 プログラムに慣れた人間ですら混乱に陥れ、書いている最中に精神力と人生の貴重な時間をガンガン削ってくれる究極の嫌がらせです。 Rust は変数のコピーしちゃうと元のやつが使えなくなるクソ仕様なのです。書き手にメリットなんて一切無い。C++の悪しきメモリ管理の呪いを持ち込んで来てその中でもさらに悪い部分をデフォルトにした感じです。 struct Point { x: i32, y: i32, } fn Print(p: Point) { println!("x = {}, y = {}", p.x, p.y); } fn main() { let mut a: Point = Point{ x: 10, y: 15 }; Print(a); // エラー！ println!("x = {}, y = {}", a.x, a.y); } Print(a) で1回コピーされているのでその後使うと死にます。ウソでしょ？と思うでしょ？ホントです。 そしてプリミティブ型ならOKと言う Java に似たダブスタの呪いもオマケで付いてます。 おかげさまで関数はほぼ全て明示的に参照渡しをするハメになります。 「だったらデフォルトそうしとけよ！ & をイチイチ書かせんなやワレ！」と思わないのってある種の才能だと思います 888 名前：デフォルトの名無しさん [2021/08/22(日) 02:59:07.86 ID:0Cz6ueFz.net] >>862 struct Point { x: i32, y: i32, } fn Print(p: &Point) { println!("x = {}, y = {}", p.x, p.y); } fn main() { let mut a: Point = Point{ x: 10, y: 15 }; Print(&a); println!("x = {}, y = {}", a.x, a.y); } これだとまぁエラーにはなりません。が、参照だからといってこんなことやったら死にます。 fn Print(p: &Point) { println!("x = {}, y = {}", p.x, p.y); p.x = 10; <- die } イミュータブルだからですって。はぁ・・・。 889 名前：デフォルトの名無しさん [2021/08/22(日) 03:01:25.00 ID:0Cz6ueFz.net] >>862 だからこう書けですって。 fn Print(p: &mut Point) { println!("x = {}, y = {}", p.x, p.y); p.x = 100; } fn main() { let mut a: Point = Point{ x: 10, y: 15 }; Print(&mut a); println!("x = {}, y = {}", a.x, a.y); } はい来た。mut mut mut mut mut mut mut mut mut ああぁぁああぁ〜〜〜！！！ なんでよく使う方を面倒臭くしたがるんですか、この言語を作っている方々は。 その他又貸しの呪いやらなにやら超盛り沢山ですし。もうね私とはセンスが全く合わないです。 ぬぅぅうぅうぉぉおぉおぁぁあぁあああ！！！！！Rustよ！もうお前には頼まん！malloc と free を俺によこせうぉるぅぁあ！！こんな訳のわからんものに付き合わされるんだったら自分でメモリ管理した方がマシだわ！！！ とよくみんな発狂しませんよね。我慢強いですね。馬鹿じゃないの。 とっても良い子である Nim にはこんな呪いある"ワケ"がないです。 890 名前：デフォルトの名無しさん [2021/08/22(日) 03:06:14.74 ID:0Cz6ueFz.net] >>862 type Point = object x: int y: int proc print(this: Point) = echo "x = ", this.x, ", y = ", this.y var p = Point(x: 10, y: 15) p.print() echo "x = ", p.x, ", y = ", p.y まぁ普通はこうですよね・・・。Rust がぶっ飛んで異常なだけです。ありえないです。 ちなみに Nim の場合 print(p) と p.print() は書き方が違うだけで意味は同じです。 891 名前：デフォルトの名無しさん [2021/08/22(日) 03:09:40.85 ID:0Cz6ueFz.net] >>862 参照で渡す場合はこうなります。 type Point = object x: int y: int proc print(this: ref Point) = echo "x = ", this.x, ", y = ", this.y this.x = 100 var p = Point.new p.x = 10 p.y = 15 p.print() echo "x = ", p.x, ", y = ", p.y new で Point object を作成すると参照のオブジェクトが出来ます。これを渡すために print 側の引数には ref をつけてあげます。new 関数でメンバに値を割り当てることは出来ないので後から渡してやります。 つっても上のやつはあくまで Rust と似せて書いたらこうなるよって話でこんな書き方しません。 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ではなくポインタが渡るのですか？ 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は「所有権」て訳されるけど意味的には「解放権」とか「解放責任」に近いかも 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] このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 69日 1時間 5分 21秒 1021 名前：過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています

---

---

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

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