Rust part11

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


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

Rust part11

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

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

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

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

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

前スレ
Rust part10
https://mevius.5ch.net/test/read.cgi/tech/1617367084/
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 の定義としては大まかに

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

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

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

②についてはメモリ管理を自動化する能力ではなく見せ方の問題だとする派閥。
スマートポインタは管理方法も管理内容も決まっていて
プログラマがそれを利用するという明示が含まれるので 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