21/08/21 05:48:08.14 lXSuJ2vU.net
hoge.iter()だと参照でhoge.iter().fuga()だとhogeの所有権ぶんどる、みたいなのは無理な気がする
810:デフォルトの名無しさん
21/08/21 06:24:06.23 kvS3AY0X.net
>>790
Vecは可変長なので必ずヒープからアロケーションが発生します
一方で配列は必ず固定長でスタックに置かれます
>>784
(&vec0).into_iter()はvec0.iter()となるので
into_iter()だけにすることも出来なくはないと思いますが
書き方が面倒なので簡潔なiter()と共存してるのだと思います
811:デフォルトの名無しさん
21/08/21 09:34:58.66 v7gED8U+.net
>>791
Cow使えばできるという話じゃないよ
lazyに所有権を取得するような機能を持った型を追加すれば
今の型システムでも表現できないってことはないんじゃないかって話
そういう型を追加することを型システムの変更と言うのであれば
今の型システムでは表現できないてのに同意するよ
812:デフォルトの名無しさん
21/08/21 09:43:26.29 KTz5aeQ/.net
>>795
アロケーションが発生するのは伸長するときだけでしょ
伸長するような用途だったら、そもそも配列使えないし
>一方で配列は必ず固定長でスタックに置かれます
だめじゃん。スタックオーバーフロー考慮するならvecの方がいいじゃん
まあ、自分も組み込み以外でスタックフレームのサイズなんて考慮したことないけど
813:デフォルトの名無しさん
21/08/21 09:50:40.59 KTz5aeQ/.net
>>795
ちなみにスタックにあることによってL2キャッシュに載りやすいだろ！
という意見ならそれは同意する。サイズが小さければね。
814:デフォルトの名無しさん
21/08/21 10:08:08.47 /0ZvMIRv.net
>>797
> アロケーションが発生するのは伸長するときだけでしょ
いいえ。
Vecの実体は必ずヒープにアロケーションされます。
Vec自体は(指定しなければ)スタック上で、ヒープへのポインタや長さなどで構成されて固定長です。
Stringも内部はVec<u8>なので同様です。
815:デフォルトの名無しさん
21/08/21 10:12:53.88 KTz5aeQ/.net
>>799
ああ、アロケーションじゃなくてヒープにってところを問題視してる？
ガベージコレクションの発生を懸念してる？
816:デフォルトの名無しさん
21/08/21 10:22:22.66 HwKH2mPW.net
>>800
Rustではガベージコレクションは起きない
しかしスタック上かヒープ上かの区別は重要
スタック上のデータはその関数を終える時に消滅する
817:デフォルトの名無しさん
21/08/21 10:31:43.28 KTz5aeQ/.net
>>801
>Rustではガベージコレクションは起きない
ヒープを使ってるんだから起きないわけないだろ
＞スタック上のデータはその関数を終える時に消滅する
Vecの中身だって関数を終えるときに解放されるでしょ
されないんだっけ？
そもそもの話は配列を使ってるところをVecにしても問題なくね？ってことなんだけど
どこが問題になるかの例を示してもらえたら、わかりやすい
818:デフォルトの名無しさん
21/08/21 10:58:14.92 Hi//C77Q.net
rustにはガベージコレクションがないんだぜ・・・
819:デフォルトの名無しさん
21/08/21 11:04:35.75 eqU3IJp1.net
デストラクタ的な機構で後始末するのはガベージコレクションとは普通言わない
820:デフォルトの名無しさん
21/08/21 11:09:11.24 JLDZmydZ.net
Cでもひーぷをつかうとがべーじこれくしょんがおきるの？
821:デフォルトの名無しさん
21/08/21 11:11:34.22 6mCMrQuL.net
ヒープへのメモリアロケーションはコストが高いから避けたいんでしょ
822:デフォルトの名無しさん
21/08/21 11:25:28.41 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:デフォルトの名無しさん
21/08/21 11:42:53.96 3jqa2oM2.net
そういや何でalloca()無いの？
824:デフォルトの名無しさん
21/08/21 12:23:12.36 kcBD0DB/.net
>>795
Box<[T; N]> のように配列がヒープに置かれる場合もある
825:デフォルトの名無しさん
21/08/21 12:35:23.13 5zDPvhJy.net
>>809
それはBoxだからであって、そんなこと言い出したら整数だってヒープに置かれうる
しかし普通に「整数型はスタックに置かれる」と言われる時は、Boxを使わない場合を意味している
Boxを使えばヒープに置かれるのは自明だからだ
したがって、整数や配列やVecの管理データ部分はそのままだとスタックに置かれるがVecのデータ実体は常にヒープに置かれる、で良い
826:デフォルトの名無しさん
21/08/21 13:25:00.39 KTz5aeQ/.net
うーん、なんだかなー
みんなヒープのことを無限にバイトを吐き出す魔法の箱かなんかだと思ってない？
>>805
>Cでもひーぷをつかうとがべーじこれくしょんがおきるの？
当然
Cのmalloc/freeやC++のnew/deleteでもガベージコレクションは発生する
wikipediaの「ヒープ領域」がよくまとってるよ
いくつかの理由からfree/deleteのガベージコレクションはJavaやC#のガベージコレクションよりも超高速だ
それでも、組み込みの世界ではガベージコレクションのせいでリアルタイム性が失われることを嫌がって、
ヒープを使わなかったりする
じゃあ、組み込みでは動的なメモリをどうするかっていうと、リンクドリストのノードをメモリブロックに
見立てて、メモリ管理システムにしたりする
これだと取得も解放も定数時間のコストだからね
>>807
すまん、例をみてますます配列なくても困らない気がしてきた
配列でできて、Vecにできないことはないの？
827:デフォルトの名無しさん
21/08/21 13:35:03.05 +9L1DmAB.net
>>811
Rustにはガベージコレクションはありません
おっしゃる通りヒープからの取得も解放も定数時間のコストで行なわれ更にガベージが溜まることはありません
Rustでは生存期間や所有権に貸し借りが明白になっているため、使用中のものが解放されたり、解放済みが使われたり、使用済みが解放されなかったりは起きません
828:デフォルトの名無しさん
21/08/21 13:50:09.86 KTz5aeQ/.net
>>812
>ヒープからの取得も解放も定数時間のコストで行なわれ
これってどういう原理？ 本当に定数ならそれもうヒープじゃないんじゃ
ヒープツリーを辿る処理も未使用ノードを結合する処理も定数時間って
ありえないと思うんだけど
829:デフォルトの名無しさん
21/08/21 14:16:15.10 G8x/1s0B.net
もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
そのためRustにガベージコレクションがないことを理解できていないような感じ？
830:デフォルトの名無しさん
21/08/21 14:22:08.01 KTz5aeQ/.net
調べた
・rustのヒープはフリーリストアロケータじゃない
（サイズごとのメモリスラブをさらに分割して使う）
・取得・解放は定数時間じゃない
(メモリスラブ全体が未使用になったときに、デフラグして別サイズのスラブとして利用可能になる)
→これ実質ガベージコレクション処理じゃん
・当然デフラグは発生するが、大して問題にならない
→そうだろうね。C++でさえアロケータ書いたことない
・問題になるならアロケータを自作することも可能(デフォルトはjemalloc)
だそうだ。
ヒープはヒープ構造じゃないのか……
831:デフォルトの名無しさん
21/08/21 14:36:21.13 KTz5aeQ/.net
>>814
>もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
freeの中にもガベージコレクション処理があるんだよという話
javaと違ってマーク＆スイープ処理いらないから早いけどね
>そのためRustにガベージコレクションがないことを理解できていないような感じ？
そんなことはわかってる
今は処理コストの話をしてる
サイズが変わらないVecと配列(配列なのでもちろん固定長)でそこまで優位の差があるのかと訊いた
そこでVecはヒープを使う(からダメだ)という答えが返ってきたので、
ヒープを使うとなぜダメなんだ？ ガベージコレクションのオーバーヘッドを気にしてるのか？と
そうするとrustはガベージコレクションありませんと言われた
じゃあ、結局のところヒープを使うとなぜダメなんだ？
832:デフォルトの名無しさん
21/08/21 14:43:58.08 3jqa2oM2.net
勝手に定義した「ガベージコレクション」なんか議論するだけ時間の無駄
833:デフォルトの名無しさん
21/08/21 14:48:02.99 HlQuVij0.net
>>816
あなたが完全に間違っている
それを世間ではガベージコレクションとは呼ばない
834:デフォルトの名無しさん
21/08/21 14:50:34.09 KTz5aeQ/.net
>>818
辞書が絶対とは言いたくないがwikipediaの「ヒープ領域」見て
835:デフォルトの名無しさん
21/08/21 14:52:48.65 Hi//C77Q.net
自分でfreeしたものをGCと呼ぶとは強者が現れたな
836:デフォルトの名無しさん
21/08/21 14:53:06.41 O7+p4qIy.net
それこそwikipediaの「ガベージコレクション」見てもらった方がいいのでは。
837:デフォルトの名無しさん
21/08/21 14:53:37.02 6mCMrQuL.net
もうジェマロクはデフォルトじゃないよ
838:デフォルトの名無しさん
21/08/21 14:58:27.12 Hi//C77Q.net
そういやこんな記事があったよ
実装言語を「Go」から「Rust」に変更、ゲーマー向けチャットアプリ「Discord」の課題とは
URLﾘﾝｸ(atmarkit.itmedia.co.jp)
> 平均すれば高速に動作していたものの、数分ごとに平均応答時間が急に大きくなり、
> ユーザーエクスペリエンスを損なっていた。調査したところ、
> これはGoの中核機能であるメモリモデルとガベージコレクタ（GC）に起因することが分かった。
> Rustではガベージコレクションが不要だ。
> 同社がRead StatesサービスをRustで実装しようと考えたのはこれが理由だ。
> Rustを使えば、Goで実装した場合に生じた平均応答時間の急増は見られないだろう。
839:デフォルトの名無しさん
21/08/21 15:02:21.85 KTz5aeQ/.net
>>820
だから、ここではコストの話をしてるんだって言ってんのに
>>821
見た。もちろん知ってる。
本題からずれてる。自動解放とかデフラグの定義の話がしたいんじゃない
配列とVecのことが知りたいんだって
なんだってこう話を逸らすんだ？
840:デフォルトの名無しさん
21/08/21 15:02:56.01 watXYiN6.net
>>819
URLﾘﾝｸ(ja.wikipedia.org)
> 7月15日（土）12:22の版で記述いただいた内容のうち、「ガベージコレクション」という部分だけ誤りと思われるので、7月19日（水）02:32の版で消させていただきました
せやな。
841:デフォルトの名無しさん
21/08/21 15:10:24.32 hSZ/tOwO.net
>>824
まずはプログラミング言語におけるガベージコレクションとは何かを理解して
次にRustではそのガベージコレクションがないことを理解して
その上で何を質問したいのかを整理してはいかがでしょうか？
それを終えてからでないとあなただけ用語の定義が異なったままでは話が進みません
842:デフォルトの名無しさん
21/08/21 15:10:57.04 IZ1Oj5x4.net
ガベコレは普通javaとかpyのコンパイラやらインタプリタがreference counterをオブジェクトに勝手に付随させる事を想定するけどな
Vec arr処理コストの違いに関してはbuffer使わないんだからarrayの方が基本的には糞みたいに早いと思うがな
そこらosとかによって最適化図られるからオブジェクト生成のとき以外は決定的な違いあんまなさそうだが
要素数をコンパイルタイムに決定(これのアルゴにもよるが)出来るなら普通はシンプル配列の方が速いよね
goはparallel threadingみたいな部分で変なgc実装してて大量に独立の計算量ハード問題導入するからねそこらへんがドイヒーなんだろうな
俺は好きだけど(´・ω・｀)
843:デフォルトの名無しさん
21/08/21 16:18:04.16 iwjgeVKb.net
>>824
何度も説明されている通り
配列は固定長なのでデータ管理部分はなく配列は通常スタック上
Vecは可変長なのでデータ管理部分がありそれは通常スタック上そして配列相当部分は常にヒープ上
844:デフォルトの名無しさん
21/08/21 16:29:59.01 0b1Dm8dh.net
コンパクションとガベージコレクションの区別がついてない
世の中のガベージコレクターがコンパクションもやってるからといって
コンパクションのみを指してガベージコレクションとは呼ばない
845:デフォルトの名無しさん
21/08/21 16:33:27.85 Ay6lvOn8.net
ふりだしに戻る >>787
846:デフォルトの名無しさん
21/08/21 16:37:39.49 KTz5aeQ/.net
>>828
それの何が問題？
stringの実装はヒープだけど問題ないよね？
こういう使い方をすると配列より100倍くらい遅いとか、メモリリークするからVec止めて配列使えとか
そういう注意点ある？
もちろんループの中でVec::newするとオーバーヘッドでかいとか、
そういうわざとらしいのはなしにして
あえていうなら初期化の記述量がちょっと増える、とか？
847:デフォルトの名無しさん
21/08/21 16:59:15.86 dJkGQ7Qm.net
>>831
誰も何も問題にしていませんよ
あなたが勘違いをして勝手な何かを問題にしているだけ
StringはVecにstructの皮を被せただけなので状況は同じ
848:デフォルトの名無しさん
21/08/21 17:06:03.36 Hi//C77Q.net
>>829
HDDの頃はよく使ってたHDD最適化と容量を増やすみたいなソフトを思い出した
HDDのデフラグ → メモリコンパクション
HDDにある不要なキャッシュの削除 → ガベージコレクション
こんな感じに似てるな
849:デフォルトの名無しさん
21/08/21 17:16:16.64 eqU3IJp1.net
ヒープがヒープ構造じゃないのかとか言ってるから本当に何も知らなかったのだろう
オレオレ用語使われると混乱するからとりあえずmalloc動画くらいみて勉強してきてほしい
850:デフォルトの名無しさん
21/08/21 17:26:30.08 KTz5aeQ/.net
>>834
そこ話の本筋じゃないんだよなー
Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー
851:デフォルトの名無しさん
21/08/21 17:30:07.73 pF+sRbnf.net
>>835
ヒープ使ってるからダメ、なんて誰も言っていない
全ては君の勘違い
852:デフォルトの名無しさん
21/08/21 17:31:33.62 KTz5aeQ/.net
>>836
そうなの？ じゃあ結論として配列はVecに置き換えても問題ないってこと？
853:デフォルトの名無しさん
21/08/21 17:52:04.92 eqU3IJp1.net
Vecは固定長配列(型[u8; 32]とかで表されるやつ)を置き換える用途としては使えないが, 逆に言えばそれだけ
854:デフォルトの名無しさん
21/08/21 18:26:53.45 Hi//C77Q.net
むしろ配列なんてクレート使わないとコンパイル時点で数値が決まってないと使えないから
ほとんど出番がないんだから、どこに悩む必要があるというのか
855:デフォルトの名無しさん
21/08/21 18:30:22.30 AgJApIsV.net
>>835
＞Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー
あなたの妄想ではないですか？
スレを読みましたが、
Vecはヒープ使ってるからダメと言われた書き込みが見当たりません。
856:デフォルトの名無しさん
21/08/21 18:31:04.95 3jqa2oM2.net
ヒープは悪であるということをハッキリと言う
857:デフォルトの名無しさん
21/08/21 18:41:19.82 tswurJ+7.net
Linux のデフォルトではスタックの大きさは 8 メガが上限じゃなかったっけ？
(Windows だともっと小さかったはず)
大きさが固定 (コンパイル時に確定する) でかつ十分に小さく寿命が短いなら配列をスタックにおく
のは性能的に有利 (確保と解放のコストが小さい) だが、大きさを見積もれないときにスタックに置くと
スタックが足りないときにどうにもできないで即死するしかない。
大きさのわからない配列はスタックに置くべきではないというのが世の常識というもの。
少なくとも高レイヤのアプリケーションでは。
858:デフォルトの名無しさん
21/08/21 20:16:15.20 3jqa2oM2.net
仮想メモリなんだからスタック8GBに設定すればいいんじゃないの？
859:デフォルトの名無しさん
21/08/21 20:43:23.20 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
URLﾘﾝｸ(nim-lang.github.io)
Nimは限りなく抑え込まれたタイプ量で高い生産
860:性とPythonのような高い可読性を実現し ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
861:デフォルトの名無しさん
21/08/21 20:47:51.35 6mCMrQuL.net
Nimは知らんがパイソンが読みやすいなんて
862:デフォルトの名無しさん
21/08/21 20:53:42.26 Z4f8T8IW.net
pythonが特別読みやすいとは思わんが、pythonで読みづらいコード書くやつが
何で実装しても読みやすいものを書くことはないだろう。
863:デフォルトの名無しさん
21/08/21 20:55:25.62 6DBrqemS.net
>>844
Pythonはたまたま外部ライブラリ充実などで普及していますが、あまりよろしくない言語です。
そのためPythonで開発したいという人はいないです。
なので「Pythonのような高い可読性を実現している」と宣伝されても逆効果。
864:デフォルトの名無しさん
21/08/21 20:58:33.68 O7+p4qIy.net
>>844の人は関係ないスレに迷惑かけて、nimユーザーのイメージダウンが目的なんだろうか。
865:デフォルトの名無しさん
21/08/21 21:35:33.43 PyG7lKVy.net
積極的にPython使おうとは思わんなぁ。インタプリタ系はRuby使っているわ
Luaも結構良い感じだと思う
866:デフォルトの名無しさん
21/08/21 21:54:02.20 tswurJ+7.net
うん。 プログラマは Python をそんなに気に入ってない場合は多いと思う。
ただ現代ではプログラミングするのはプログラマとは限らない。
Python は元々はコンポーネントを組み合わせる、いわゆるグルー言語として設計されていて、
エンドユーザ向けの性質を持っている。 BASIC 系と似た立場かな。
このくらいに制限されていたほうがかえって使いやすいという場合は確かにある。
必要なコンポーネントが出そろっている状況で上位のロジックを組み立てる分には
Python も便利なこともあるにせよ、言語としての出来はそんなに良くない。
867:デフォルトの名無しさん
21/08/21 21:59:07.63 7GAoG1Iq.net
>>845
>Nimは知らんがパイソンが読みやすいなんて
Pythonは構文にインデントを組み込むことによってざっと眺めた時に人間が読みやすい
一般的には上記の事をPythonは高い可読性があると表現されています
この事は「Pythonは可読性の高い言語」ググれば約 265,000 件出てきます
他の言語と可読性は同じだろって意見の人もいますが少数派ですね
868:ハノン
21/08/21 22:21:31.89 .net
>>851
ｽﾚﾘﾝｸ(tech板:963番)
「javascriptは可読性の高い言語」で検索すると約 334,000 件
869:デフォルトの名無しさん
21/08/21 22:31:37.65 7PPLxZL+.net
元の文脈的に
nimも構文にインデントを組み込んでるからpythonが出てきただけでそういう議論がしたいんじゃないと思う
870:デフォルトの名無しさん
21/08/21 22:36:10.82 7GAoG1Iq.net
>>852
>「javascriptは可読性の高い言語」で検索すると約 334,000 件
単に検索件数が多いだけで、上位10件の表示内容を読んでも
「javascriptは可読性の高い言語」と言う内容のページは1つも見つかりません
対して「Pythonは可読性の高い言語」は上位10件の内5件見つかりました
871:デフォルトの名無しさん
21/08/21 22:41:14.03 7GAoG1Iq.net
>>853
おっしゃる通りです(/ω＼)
872:デフォルトの名無しさん
21/08/21 22:56:47.50 lXSuJ2vU.net
ただのコピペ荒らし
まったくRustもNimも関係ないスレでも見るし
873:デフォルトの名無しさん
21/08/21 23:00:47.35 YSvCkW+D.net
Rust Tourだけやっていても作業の流れが身につかなさそうなので、写経を始めました
そこでまず出くわしたのがTokioのバージョンの壁で、バージョンによって動いたり動かなかったり差がありました
クレートの無難なバージョンがどれか、クレート同士の無難な食い合わせはどれか、など、どうやって知れば良いのですか？
874:デフォルトの名無しさん
21/08/21 23:07:06.11 7GAoG1Iq.net
>>857
Nimの写経を始めましょう
875:デフォルトの名無しさん
21/08/21 23:07:52.34 kcBD0DB/.net
写経なら写し元と同じバージョンにそろえるのがよいのでは
876:デフォルトの名無しさん
21/08/21 23:24:51.23 7GAoG1Iq.net
>>859
>写経なら写し元と同じバージョンにそろえるのがよいのでは
Nimのバージョン 1.5.1を写経しましょう
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
URLﾘﾝｸ(nim-lang.github.io)
877:デフォルトの名無しさん
21/08/21 23:48:46.37 PyG7lKVy.net
組み込み系ではMicroPythonが流行っているらしいが全く魅力を感じないｗ
878:デフォルトの名無しさん
21/08/21 23:53:13.51 +zMEbJ+6.net
Nimを調べてみたのだが
Rustよりも高機能な点を見つけられなかった
もし有るならば書いてください
無ければ去ってください
879:デフォルトの名無しさん
21/08/22 02:15:33.57 0Cz6ueFz.net
>>862
>Nimを調べてみたのだがRustよりも高機能な点を見つけられなかった
>もし有るならば書いてください
>無ければ去ってください
そんな寂しい事言わないでかまってよ～(´;︵;`)
行末のセミコロンが必要ない
タイプ数がもりもり減ります。
Rust にはもちろん必要です。
main が要らない
スクリプト言語感覚でいきなりコードを書けます。
Rust は main が必要です。
>Nimキチガイ
いつもみんなによく言われます
いや～照れますね～ｖ（=＾0＾=）ｖ
880:デフォルトの名無しさん
21/08/22 02:16:39.23 KEfgBimj.net
>>863
nimのスレ立ててそっちでやってよ
881:デフォルトの名無しさん
21/08/22 02:32:40.46 w5XnK8W7.net
>>863
あなたは知恵遅れか何か？
Rustより高機能な点を問われているのに、セミコロンが必要ないとかどうでもいい話しかできないの？
答えられないならここから出ていきなさい。
882:デフォルトの名無しさん
21/08/22 02:33:23.15 j+Q/a+4n.net
構うな
さっさとNG
883:デフォルトの名無しさん
21/08/22 02:35:27.65 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:デフォルトの名無しさん
21/08/22 02:38:26.87 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:デフォルトの名無しさん
21/08/22 02:44:19.98 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:デフォルトの名無しさん
21/08/22 02:55:06.51 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:デフォルトの名無しさん
21/08/22 02:59:07.86 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:デフォルトの名無しさん
21/08/22 03:01:25.00 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:デフォルトの名無しさん
21/08/22 03:06:14.74 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:デフォルトの名無しさん
21/08/22 03:09:40.85 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:デフォルトの名無しさん
21/08/22 03:11:53.65 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:デフォルトの名無しさん
21/08/22 03:16:29.28 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:デフォルトの名無しさん
21/08/22 03:20:10.82 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:デフォルトの名無しさん
21/08/22 03:23:05.87 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:デフォルトの名無しさん
21/08/22 03:24:44.35 0Cz6ueFz.net
>>862
分配束縛
Nim は標準ではできませんが
URLﾘﾝｸ(github.com)
を突っ込むことで可能です。
897:デフォルトの名無しさん
21/08/22 03:26:55.98 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:デフォルトの名無しさん
21/08/22 03:31:02.98 0Cz6ueFz.net
>>862
コンパイラがケチくさくない
nim c -r hoge
これで hoge.nim をコンパイルします。
拡張子なんて指定する必要ありません。
-r で実行もします。
Rust の場合
rustc hoge <- ダメ
コンパイルと同時に実行しようと思ったら
rustc hoge.rs && ./hoge
うーん・・・
899:デフォルトの名無しさん
21/08/22 03:36:37.77 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:デフォルトの名無しさん
21/08/22 03:40:59.41 EcXIWh+x.net
>>882
無知がやるとそうなるわな
901:デフォルトの名無しさん
21/08/22 08:37:49.63 0Cz6ueFz.net
>>883
>無知がやるとそうなるわな
バカ丸出し
Nimは標準実装されたnimコンパイラが強力なマクロで
最適化されたCのソースコードを吐き出して、Cコンパイラ
で極小バイナリまで生成するから、コンパイルするだけで
後はプログラマがする仕事が無いので怠けててもいい
Rustは標準実装されたコンパイラでコンパイルするだけでは
超巨大なバイナリを生成するので、最適化せれたチューニング
を施して小さなバイナリを生成�
902:ｵなければならないから プログラマの仕事が増えて怠けられない
903:デフォルトの名無しさん
21/08/22 08:40:06.97 BRNN665g.net
>>884
仕組みすら理解してないのか
904:デフォルトの名無しさん
21/08/22 08:43:57.27 c6eQFYhO.net
>>880
それはブロックスコープといって多くの言語が備えておりプログラミングの基礎です
まさかNimには存在しないのですか？
905:デフォルトの名無しさん
21/08/22 08:57:00.52 QorwbXcj.net
rustスレでnim nim言ってる奴荒らしだろ
906:デフォルトの名無しさん
21/08/22 09:00:12.62 0Cz6ueFz.net
>>862
マクロのシンタックスを別で覚える必要がない
Rust のマクロは構文が全く変わってしまいます。
そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。
公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに
由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で
「なんじゃそりゃ」と言う言葉しか出ません。
Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための
障壁の低さは比べ物になりません。
907:デフォルトの名無しさん
21/08/22 09:19:59.80 k4RSCji3.net
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
ｽﾚﾘﾝｸ(tech板)
908:デフォルトの名無しさん
21/08/22 09:21:24.81 k4RSCji3.net
nim
ｽﾚﾘﾝｸ(tech板)
909:デフォルトの名無しさん
21/08/22 09:49:19.77 sxhQ+hXZ.net
実際rustって色々リンクするから、最小バイナリでかいよな
でも、それで困ったことってあるか？
俺はない
910:デフォルトの名無しさん
21/08/22 09:53:06.17 DrnSGK6Q.net
>>891
それはリンクする状況にするからであってRustのせいではない
例えばRustを使って組み込みやWASM等でもバイナリでかいと思ってないよね
911:デフォルトの名無しさん
21/08/22 10:05:41.39 qkR4Cuiq.net
Rustは他に比べれば最小のバイナリでしょ、コンパイラ/リンカーが長い年数を掛けて最適化されたCより大きいが。
一番不満なのが公式はビルドが速いというがそんなに早くない事だけ。それ以外は従来のC/C++（C++17/20/23
なんかを除く)より圧倒的に安全だし、明示的であるからこそタイプ量が多い。
Nimに比べて大きいというのはRustのコンパイラがまだCを吐き出してた頃から最適化されていないから、Nimと
いうかGCCやClangに比べ、ほんの少し大きくなる。リンクするものが大きければバイナリが大きくなるのは
当然でGoなんかはまさにそれでしょ、goroutineを共有ライブラリに押し込めることは出来ないから
912:デフォルトの名無しさん
21/08/22 10:06:16.71 sxhQ+hXZ.net
>>892
まあ、ユーザコード自体のサイズがでかいわけじゃないのは同意
913:デフォルトの名無しさん
21/08/22 10:17:01.78 qkR4Cuiq.net
もう１つ不満がある事は、Rustならメモリーリークしないと言う奴がいる事、公式も明言してる通り
グローバルの循環参照を作成してしまえば簡単にリークするのに、意識高い系のコード書かないやつが
メモリーリークしないんだと他の言語も触ったことの無い初心者に力説する事。盛大にリークしてて
正常に動いてるプログラムを直すのは大変・・・
ま、これは言語のせいじゃないけどね、他は凄い良く出来てる、Linuxカーネルに採用されるような
他の言語（第３の言語）は当分出てこないだろうと思うほど
914:デフォルトの名無しさん
21/08/22 10:35:44.30 FTtcJrTl.net
Rustのメモリ安全性は、メモリリークしない、ではないからな。
915:デフォルトの名無しさん
21/08/22 10:40:22.74 VB7b1YKz.net
>>895
Rustは弱参照があるから強参照の循環参照を作らずに済みます
よってまとまなプログラミングをしていればメモリーリークは起きません
916:デフォルトの名無しさん
21/08/22 10:42:20.85 sxhQ+hXZ.net
>>895
javaでも同じことを言う奴がいる
「GCが頻発する。GC壊れてる」
壊れてるのはお前のコードだ
917:ハノン
21/08/22 10:52:46.02 .net
>>867
構ってあげるから別スレ建ててください
C へのトランスレータであることは魅力的ですよね
918:デフォルトの名無しさん
21/08/22 10:54:43.87 j+Q/a+4n.net
>>895は分かってる人だろう
ちゃんと読んでるか？
919:デフォルトの名無しさん
21/08/22 11:49:45.30 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:デフォルトの名無しさん
21/08/22 12:16:08.62 0Cz6ueFz.net
>>862
Rust の良いところ
さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。
Rust にも良いところはあります。
fn <- 短い！
proc <- 長い！
これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。
921:デフォルトの名無しさん
21/08/22 12:22:55.13 pVXVequb.net
>>902
どうでもいいだろ
それが0文字の言語も8文字の言語も併用しているが長さで困ったことはない
タイプ数を気にするのは愚か者だけだ
922:デフォルトの名無しさん
21/08/22 12:30:03.84 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:デフォルトの名無しさん
21/08/22 12:37:43.49 vEK5NNFF.net
>>895
他の言語に比べれば循環参照を作るハードルはかなり高いでしょ
現実的な用途でborrow checkerに引っかからないような循環参照を作って
リーク以外は機能的に問題ないコードを書くのは初心者には難しいと思う
924:デフォルトの名無しさん
21/08/22 12:55:40.93 QorwbXcj.net
さすがにマルチポストは荒らし以外の何物でもないな
925:デフォルトの名無しさん
21/08/22 13:03:58.26 sxhQ+hXZ.net
>>904
the compiler will collapse the discriminant of the first option into the second.
って言ってるから
Option<Option<u8>>はOption<u8>に変換されるってことじゃない？
926:デフォルトの名無しさん
21/08/22 13:18:58.50 cSh20jP2.net
>>554-555
あたりが物になるのはいつかなぁ
組み込みだとLLVM縛りは結構きつい
927:デフォルトの名無しさん
21/08/22 13:46:33.46 j+Q/a+4n.net
>>904
Optionで9回包んでもsizeは2のままだったのでそういうわけではなさそう
None, Some(_), Some(Some(_)) の3バリアントがあるのと同じようなレイアウトになる模様
↓はOption<Option<Option<u8>>>の例
URLﾘﾝｸ(play.rust-lang.org)
928:デフォルトの名無しさん
21/08/22 14:20:53.63 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:デフォルトの名無しさん
21/08/22 14:35:04.66 vEK5NNFF.net
[0..=3]<u8>になってるね
nightlyで#[rustc_layout(…)]を使うと確認できる
#![feature(rustc_attrs)]
#[rustc_layout(abi, size, debug)]
type Foo = Option<Option<Option<u8>>>;
930:デフォルトの名無しさん
21/08/22 15:31:41.81 PExPKGEq.net
Itertoolsが便利すぎて今までの自分が可愛そうすぎる(´･ω･`)
931:デフォルトの名無しさん
21/08/22 17:33:05.93 0Cz6ueFz.net
>>862
技術書典に出会っていなかったら俺はNimをさわってないと思う
背景
俺たち「そろそろ技術書典に参戦するか」
俺たち「何書く？」
俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」
ワイ「(マイナーの定義はさておき)Nimでオナシャス」
ワイ「(アドカレあるし、記事まとめておくかぁ...)」
Nimとは？
Nim は アンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、
コンパイル言語という特徴を持つプログラミング言語です。
アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々
な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。
それがNimプロジェクトの始まりで、2005年頃のようでした。
当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から
2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。
932:デフォルトの名無しさん
21/08/22 18:20:04.94 qHvaNpwK.net
結局rustもC++を遥かに超える型地獄なんだな
933:デフォルトの名無しさん
21/08/22 18:47:16.61 eu6eNh6V.net
こんだけ型がっちがちに固められた言語触っちゃったら他の言語に戻れない
PythonとかPythonとか
934:デフォルトの名無しさん
21/08/22 19:10:19.80 E7wqFzW/.net
型地獄って何？
935:デフォルトの名無しさん
21/08/22 19:11:44.78 CqI7brJQ.net
二度と出られぬかーたーじーごーくーーー
936:デフォルトの名無しさん
21/08/22 19:15:51.20 +34cYDX+.net
実行時にバグるよりコンパイルエラーでコンパイル出来ない方が遥かに優れていると思ってるけど, そう思わないと型が辛くなるだろうなぁ
937:デフォルトの名無しさん
21/08/22 19:27:07.94 PExPKGEq.net
JavaScriptで組んでたときに、文字の数字を数値型に変換したくて、
"10" + 0
みたいにしてたことを思い出した
938:デフォルトの名無しさん
21/08/22 20:28:11.75 O/1WEaVf.net
C++でしんどいの型の部分じゃないけどな
939:デフォルトの名無しさん
21/08/22 20:45:47.91 JES5Vdct.net
>>919
JSようしらんけどこれって"100"にならないんだ？
940:デフォルトの名無しさん
21/08/22 21:02:27.49 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:デフォルトの名無しさん
21/08/22 21:06:05.83 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:デフォルトの名無しさん
21/08/22 22:37:49.54 Wmq9vv9f.net
RustにはGCないから云々言われるけどメモリ以外のリソースもRAIIとムーブセマンティクスの力でいい感じに扱えるのは良いよね
他の言語だと with 式などでスコープ抜けたら解放は出来るけど
クロージャにキャプチャされる場合など長時間生き残るようなケースをちゃんと扱えたりするのだろうか
943:デフォルトの名無しさん
21/08/23 00:06:22.12 q1PbYAS3.net
>>921
"100"になるよ
944:デフォルトの名無しさん
21/08/23 00:25:43.80 WImWpxqb.net
>>898
JavaはグローバルのGCがあるから意味が違うよ。リークしているように見えるがプログラムが正常に
終了をすればGCが起こる（だからJavaは停止時にフリーズしたようになるプログラムが多数）
>>905
ハードルは高くないよ。循環参照をWeak<T>でなくRc<T>で書いてしまえば普通にリークする
リファレンスカウントになっているのだから当たり前だけどね
URLﾘﾝｸ(doc.rust-jp.rs)
945:デフォルトの名無しさん
21/08/23 01:03:20.75 LyXSTYiq.net
GC言語にも弱参照はあるのでまともなプログラマーならば強循環参照は作らない
RustはGCが無しでメモリ安全性を保証できる言語であるとともにメモリリークも避けることができる言語
946:デフォルトの名無しさん
21/08/23 01:18:03.41 9dmEVPj+.net
GCは強循環参照も問題なく回収できるんだよ
947:デフォルトの名無しさん
21/08/23 01:30:55.93 gt/OOSS+.net
>>928
GCは方式の異なる段階があって
弱参照を使う循環参照なら強参照カウンタだけで回収できる
強参照のみの循環参照までも回収する方式は様々あるけどいずれも重い
だからGC言語にも弱参照があって賢い配慮あるプログラマーが使えるようになっている
948:デフォルトの名無しさん
21/08/23 02:08:47.17 mUiDivSN.net
>>926
その日本語訳に書いてる通り
「循環参照は簡単にできることではありませんが、不可能というわけでもありません。 Rc<T>値を含むRefCell<T>値があるなどの内部可変性と参照カウントのある型がネストして組み合わさっていたら、 循環していないことを保証しなければなりません;」
RefCell<Rc<T>>を使いこなせるのに循環参照で盛大にリークさせる人も
Rc<T>をWeak<T>に直すのが大変っていう人も
かなりの激レアさんだと思う(個人の感想)
949:デフォルトの名無しさん
21/08/23 08:54:29.06 7vUkULmy.net
>>929
誤り
GC言語の弱参照は強循環参照対策ではなく、キャッシュなどで長寿命のオブジェクトがGCを妨げることを避ける目的で使用される
だから例えば、ウインドウはボタンを管理しボタンは自身がクリックされたことをウインドウに通知する、ただしボタンが動的に追加削除されることはない、
といったような互いに寿命が一致する循環参照が生じるケースでは弱参照は普通使用しない
マークアンドスイープは十分に高速なので、参照カウンタをGCと併用するのはあまり一般的ではない
950:デフォルトの名無しさん
21/08/23 08:57:57.29 ksTslrDC.net
ネストしたstructの奥深いところにひっそりRcが隠れてたら
知らない間に循環参照になってることもあるかもしれない
951:931
21/08/23 09:17:05.48 7vUkULmy.net
念のため補足しておくが、寿命が一致しない循環参照の場合は弱参照を使わなければならないというわけではない
ウインドウとボタンの例でいうと、普通に考えてボタンが動的に削除されようとしていることをウインドウが知らないわけないから、そのタイミングでウインドウが持つボタンへの参照を削除すればいいだけだ
GC言語で弱参照が必要とされるのは極めて特殊なケースに限られており、ほとんど使用されることはない
952:デフォルトの名無しさん
21/08/23 09:53:29.91 IzWPiInz.net
>>933
特殊なケースではないと思う
GC言語でも何らかのツリー構造をあつかうことはよくあって
その時に親から子へは普通に強参照でも子から親へは弱参照の方が有利だよね
弱参照を使っていれば一部のサブツリーを捨てた時に循環参照ではなくなる
これはGC言語だけではなくRustでも同様で、サブツリーを捨てたらそのトップへの強参照が消えて連鎖的にサブツリーが回収されますよね？
953:デフォルトの名無しさん
21/08/23 10:15:02.98 6chE64yn.net
>>934
別に有利じゃないから普通にどっちも強参照使うのが普通だよ
マークアンドスイープは循環参照で遅くなったりしないから
954:デフォルトの名無しさん
21/08/23 10:25:19.17 9/DhhYFq.net
>>935
マークアンドスイープ方式のみでGCする言語ばかりではない
GCは奥が深い
弱参照の使用はそこで有利
955:デフォルトの名無しさん
21/08/23 10:28:37.19 6chE64yn.net
ちなみにGC言語は常に強参照を使うことを前提に最適化されているので、必要もないのに弱参照を多用すると確実に遅くなるよ
Javaだと弱参照それ自体がヒープアロケーションされるオブジェクトだったりするので、とんでもなく非効率だ
956:デフォルトの名無しさん
21/08/23 10:36:03.26 ZbJNhF7k.net
>>937
Rustでは弱参照を使うデメリットありますか？
957:デフォルトの名無しさん
21/08/23 10:50:20.08 6chE64yn.net
>>938
生存期間を意識した非対称なコーディングをしなければならないこと、だね
親子関係の循環参照でどちらを弱参照にすべきかはケースバイケースであり、>>934が思っているほど単純な話ではない
別にRustを批判してるわけじゃないが、GC言語から見ればそれ自体がデメリットなんだよ
958:デフォルトの名無しさん
21/08/23 11:23:41.21 XXiZs56E.net
これまでRust書いている時にトレーシングGCが欲しくなったことはありますか？
それはどのようなプログラムを書いている時ですか？
959:デフォルトの名無しさん
21/08/23 11:40:32.83 ueMbvV/8.net
>>934
その通り。
ツリーでなくてもある地点から一方向のみの有向グラフになるような強参照の時
そのある地点が解放されれば残りも解放される
960:デフォルトの名無しさん
21/08/23 13:03:00.15 mUiDivSN.net
PythonやSwiftの自動参照カウント方式はGCとは呼ばない派がいるんだね
Rustの場合は弱参照を使うかどうかに関わらず
生存期間を常に意識してコーディングする必要がある
どちらを弱参照にすべきかは所有権を考えれば明白
961:デフォルトの名無しさん
21/08/23 13:26:39.80 gvYYeNdp.net
C++ スレでスマートポインタが GC かどうかという話題が出たことあるわ。
そこで現れた GC の定義としては大まかに
① 十分に信頼してメモリ管理をまかせることが出来る能力がある
② メモリ管理を意識することなく利用できる
のいずれか (または両方) が上げられていて、
その上で信頼性の程度、意識するというのがどの程度のことを言うのかで
様々な線引きがある感じだった。
たとえば①については参照カウンタだと循環を解決できないが、
それはエッジケースでしかなくてたいした問題じゃないと考えるか
そうでないかは人によるが、いずれにしてもまかせるに足る能力で
考えるという考え方。
②についてはメモリ管理を自動化する能力ではなく見せ方の問題だとする派閥。
スマートポインタは管理方法も管理内容も決まっていて
プログラマがそれを利用するという明示が含まれるので GC ではないという考え方もあるし、
管理の開始こそ明示的な宣言ではあるものの
直接的な管理は隠されているので GC だという主張もある。
どちらに線を引くかは異論があるにせよ、プログラマの側からどう「見えるか」という
抽象度の問題とする考え方。
962:デフォルトの名無しさん
21/08/23 13:46:29.34 VyqoTEns.net
>>943
違うよ
GCの定義は明白で
「ガベージが生じて溜まっていってそれらをまとめてコレクションすること」
だからRustで例えばノードツリーのトップが何らか任意の方法でドロップとなった時
連鎖的にツリー全体が次々とRcの強参照カウント0となりツリー全体が解放されるのはGCではない
即座に消えてガベージは溜まって行ってないため
963:デフォルトの名無しさん
21/08/23 14:21:58.28 cpmwRu6w.net
>>944
明白か？
そんな定義は無いと思うが。
GCの起源はLISP由来だと思うけど、その時の実装は参照カウントでは？
964:デフォルトの名無しさん
21/08/23 14:28:20.76 cpmwRu6w.net
あ、すまん。LISPはマークアンドスイープで、その後に参照カウントが発明されてるわ。
965:デフォルトの名無しさん
21/08/23 14:53:47.52 HA74v0pt.net
>>945
参照カウント方式か否かは焦点ではなくて、ゴミがたまっていってまとめて処理することをgarbage collectionと呼ぶ。
RustのRc利用はゴミがたまっていかないのでGCと呼ばれていない。
966:デフォルトの名無しさん
21/08/23 15:46:33.74 a+6ajIdY.net
>>944
「溜まっていってそれらをまとめて」というのは間違いだな。
wikipediaの記載にある
「不要になった（メモリ）領域を自動的に解放する機能」
というのが正しい。
ポイントは「不要と判断」して「解放」というところ。溜まる必要もまとめて解放する必要も無い。
967:デフォルトの名無しさん
21/08/23 16:12:57.05 gvYYeNdp.net
個人的には GC であるかそうでないかという議論はそれほど意味が感じられない。
GC という切り口からメモリ管理を見ることが出来るという切り口だと考えてる。
極論すれば C の自動変数も「スコープを抜けたら不要 (ということにする) と判断」して「解放」してるので
GC の一種と言えば一種とも見れるし、しかし参照 (ポインタ) が残ってるかもしれないし
それを経由してアクセスしたらワヤになるので (GC としては) 出来が良くねぇなぁってだけのこと。
968:デフォルトの名無しさん
21/08/23 16:20:23.00 I6cNZKXd.net
>>948
Garbage Collectionなのだからゴミ集め
ゴミが溜まったら拾い集めること
RustのRc利用だとゴミは溜まらないので「RustにはGCはない」と世間でも言われている通り
969:デフォルトの名無しさん
21/08/23 16:26:13.36 7qCp8Y9u.net
即時解放はGCじゃないと思うわ
スマポも即時解放なのでGCじゃない派
970:デフォルトの名無しさん
21/08/23 16:27:26.84 7qCp8Y9u.net
逆に言うと解放のタイミングが基本的に制御できない、つまりIDisposableみたいなのが必要になるならGCという認識
971:デフォルトの名無しさん
21/08/23 16:40:48.46 gvYYeNdp.net
ほとんどの場合に参照が 0 になるより前にゴミになっているが
ゴミであることがわかるのがカウントが 0 になったときなんだ。
カウントが 0 になったときをゴミになったときだと定義づけるのは因果が逆転している。
972:デフォルトの名無しさん
21/08/23 16:59:28.87 2x1SlAHu.net
それは言葉遊びだな
973:デフォルトの名無しさん
21/08/23 17:08:30.56 vyeTxMra.net
>>953
参照0より前にゴミになった状態を把握する一貫した方法を示せれば貴方が勝てる可能性がある。
示せなければあなたの負け。
974:デフォルトの名無しさん
21/08/23 17:39:51.03 gvYYeNdp.net
>>955
小学生かｗｗｗ 勝負してるわけじゃないだろ。
俺は GC とそうでないものを分ける意味があまりないという立場だ。
「即時」とそうでないものが GC かどうかを分ける境界だという主張に対して
実際には即時に近いものもあればそうでないものも中間もあってそのどこに
線を引けるのかは自明ではなく程度問題だと考えている。
975:デフォルトの名無しさん
21/08/23 18:01:17.23 xSD6Fm/R.net
>>948 その基準だとCの自動変数解放もGCになるね。
976:デフォルトの名無しさん
21/08/23 18:04:49.13 fiEjE9/t.net
中間なんてあるか？
977:デフォルトの名無しさん
21/08/23 18:20:07.16 ksTslrDC.net
>>957
さすがにスタックフレームの移動は含まないんじゃないか
978:デフォルトの名無しさん
21/08/23 18:29:19.97 OwFrNtUI.net
>>959
関数を終える時点でゴミとなるので解放
だからRcと同じ即時解放タイプとなる
私は即時解放するならばGCでないと考える
だからRcやスタック変数はGCではない
つまりRustにはGCはないとの定説通り
979:デフォルトの名無しさん
21/08/23 18:59:47.21 a+6ajIdY.net
>>957
システムが不要と判断して開放しているならそうだが、実際には違う。
まだ必要（ポインタとかで参照されている）としている領域でもスコープから抜ければ削除されるから、「不要になった領域を削除する機能」とは言えない。
980:デフォルトの名無しさん
21/08/23 19:39:34.81 cpmwRu6w.net
>>947
まとめて処理しなくてもcollectionだろ。
お前がフィギュアを集めてるとして、欲しいものを溜めて一気に買ってるのか？
定期的に収拾する事自体がcollectionじゃん。
981:デフォルトの名無しさん
21/08/23 19:41:33.72 XXiZs56E.net
まとめて処理しないとGCではないというのなら
GCのパラメーター変更して毎命令処理の度にGCが走るようにしたらGCではなくなるということ？
982:デフォルトの名無しさん
21/08/23 19:43:45.53 XXiZs56E.net
与太話はさておきただ単にGCと言うだけでは伝わりにくいから
トレーシングGCとかリファレンスカウント(GC)とか言った方がよいのでは
983:デフォルトの名無しさん
21/08/23 19:48:18.23 u6qceEgo.net
>>964
そこは論点ではない
リファレンスカウントでも即時解放していればGCではない
ガベージが貯まってから解放処理をしていればGC
984:デフォルトの名無しさん
21/08/23 20:08:33.56 /6K8Gxc1.net
所有権を設定して、ブロックスコープを抜けた所有権のある変数はすべて開放とかよく考えたよね
985:デフォルトの名無しさん
21/08/23 20:15:04.57 2vdDGXAS.net
リファレンスカウントは、c++のスマートポインタみたいな循環参照でリークするのと、pythonみたいに循環参照してるゴミを後から回収するのがあるから、後者はリファレンスカウント(GC)と呼ぶべきということでしょ？
前者はGCではない
986:デフォルトの名無しさん
21/08/23 21:23:06.49 uNBAsbKx.net
全く関係ない話するけど、
Rustは、可変参照型の変数を右辺に書いて、moveのソース側にすることは
可能？
それとも、moveのソース側は、普通の所有権がある可変変数でないとダメ？
987:デフォルトの名無しさん
21/08/23 21:41:50.19 mUiDivSN.net
>>968
moveのソース側って？
ownedの引数にmutable borrowは渡せない
fn foo(mut i: i32){…}
let x = 42;
foo(&mut x); // error
988:デフォルトの名無しさん
21/08/23 21:49:03.56 uNBAsbKx.net
>>969
let x = 構造体名{初期化メンバの列};
let y = x;
と書いた場合、x の内容がy に moveされるけど、
let mut x = 構造体名{初期化メンバの列};
let z = &mut x;
let y = *z;
とすることは可能？
989:デフォルトの名無しさん
21/08/23 22:02:36.97 mUiDivSN.net
>>970
なるほどそういうことか
構造体がCopyなら可、Copyじゃなければ不可
990:デフォルトの名無しさん
21/08/23 23:33:12.95 7m4C54nZ.net
GCという言葉がそこまで細かく使わなきゃいけない言葉になってることに意味がない気がする
991:デフォルトの名無しさん
21/08/23 23:50:41.85 uNBAsbKx.net
>>971
Copyって、Cloneじゃなくて POD 的な場合に単純コピーされるというやつの事？
992:デフォルトの名無しさん
21/08/23 23:57:23.53 z0XKxUto.net
>>973
便乗質問
ムーブで関数に渡してもコピーできない型はcall by valueではなくポインタが渡るのですか？
993:デフォルトの名無しさん
21/08/24 00:18:52.33 MkJE9y3A.net
>>973
Copy はトレイトだがそれ自体はただのマーカーでしかなく特に実装しなければならないメソッドはない。
Copy が実装された型はムーブの文脈でコピーになる (所有権を奪わない)。
URLﾘﾝｸ(doc.rust-lang.org)
clone �
994:� (必要な文脈では) 自動で呼ぶってだけ。 複製の仕方は Clone の実装のほうに従う。
995:デフォルトの名無しさん
21/08/24 00:33:59.68 MkJE9y3A.net
>>974
ムーブの実態はビット単位のコピー。
ムーブ元は「今後絶対に使われない」という静的な強力な保証があるから
有効なオブジェクトはひとつだけなんだ。
ビットパターンの複製は作られるよ。
コピー (クローン) という用語は Rust 的にはあくまでも静的な所有権管理と紐付いていて
機械語レベルでデータが複製されるかどうかとは関係がない。
996:デフォルトの名無しさん
21/08/24 08:40:18.86 wPEcGzhk.net
>>930
お互い個人の感想なので強くは言いませんが、公式に上がっている例を見ていただければ、たった数十行で
リーク構造を作れることは分かってもらえると思います。
あなたが言う通りにRc<T>の特性を知って使いこなしているのであれば別ですが、初心者が全て知っている事は
稀、レアというよりあり得ません。またRc<T>をWeak<T>に直すのが大変という話ではありませんよ。
データ構造上のリング構造や、ツリー上に出来てしまった循環参照を前提に（リークはするが）動いている依存
コードが多量にあるプログラムを影響を与えないように直すのが難しいという話です。これはRustではなくても
他の循環参照を明示的に破棄しないプログラムを書いてしまえば同じ事ですが。
Rustは大変に高パフォーマンスで、明示的な制御が効きますが>>895で言っているのは技術レベルが違う二者で
苦労する人が一定数発生する事でしょう。言語とはほぼ何の関係ありませんが
997:デフォルトの名無しさん
21/08/24 08:45:48.38 wPEcGzhk.net
まあ将来的にはコンパイラーがより賢く・早くなれば循環参照で増え続けるリークに対してコンパイルエラーにも
出来ると思うので、今は未だ、リークする可能性があろうとRustが良い言語だという認識は変わらない。
他の言語でも当然リークチェックは出来るが、GCを前提とするならコンパイルエラーが出ても、なぜエラーなのか
理解しずらいかもしれない。
998:デフォルトの名無しさん
21/08/24 08:48:26.31 GKvpHEIf.net
行数の問題ではなく、Rcを使って独自のデータ構造を作るスキルがあるのに循環参照だけ知らない初心者、というのはレアということでは
まぁそれはそれとして直すのが難しいケースがあるのは同意
999:デフォルトの名無しさん
21/08/24 09:23:53.65 OGtUhL4y.net
・Rustで循環参照が起きるにはRc利用が必須
・Rc利用者は循環参照の存在もそれを避けるWeakの存在も知っている
・したがってRustでメモリリークを生じさせる者はレアケース
・Weak(弱参照)を適切に上手く用いて循環参照を避けるのが大変な場合もあるが全ての言語で共通の問題でありRustの問題点ではない
1000:デフォルトの名無しさん
21/08/24 12:45:30.39 PednkAUi.net
>>971
なるほど。Rustのオブジェクト型であるところの struct はデフォルトでは
Copy trait は実装されないので、>>970 の後半のように借用を介して
moveのsource側にすることは禁止されているということなのね。
1001:デフォルトの名無しさん
21/08/24 15:09:04.48 KCG/N/Sb.net
rustってどうやって二重開放のリスク防いでるの？全然ピンとこない
1002:デフォルトの名無しさん
21/08/24 15:50:18.44 tu56M8w7.net
ownershipが１つしかない状態を維持しつつownershipが0になったら（確実に）解放する感じ
ownershipはどこかの変数が直接的or間接的に保有してて
同じリソースに複数のownershipが発生しないように
代入とか関数の受け渡しでmoveしたりborrowしたりする
少し逸れるけど解放処理を必要としないデータはCopy可能な場合が多い
ownershipは「所有権」て訳されるけど意味的には「解放権」とか「解放責任」に近いかも
1003:デフォルトの名無しさん
21/08/24 16:38:09.46 Cd1Pd2YU.net
>>977
公式の見解を個人の感想と一緒にするなよ
1004:デフォルトの名無しさん
21/08/24 17:46:18.00 uCQTu6bl.net
Rustで循環参照作るの簡単とか言ってるやつは100%エアプだからほっといてやれ
他言語での経験をあたかもRustで経験したかのように語りたかったんだろう
1005:デフォルトの名無しさん
21/08/24 18:15:27.00 otdRB8MX.net
>>985
メモリリークの原因になるかどうかを別にすれば、循環参照自体は普通に簡単に生じるだろう
1006:デフォルトの名無しさん
21/08/24 18:45:16.53 tu56M8w7.net
unsafeでポインタ使えば簡単だろうけどライフタイムのある参照の循環は大変そう
'a > 'bと 'b > 'aを両立は不可能に見えるけど何か抜け道あるのかな
1007:デフォルトの名無しさん
21/08/24 18:55:37.63 SZKxopPy.net
循環参照どころか連結リストも荷が重い
1008:デフォルトの名無しさん
21/08/24 19:43:21.83 KCG/N/Sb.net
>>983
なるほどサンクス
リージョン理論に線形論理を上手く組み合わせて、cycloneとかの欠点を克服したrustってすげーなあ
とはいってもそもそも二重開放してエラーになるというのがピンとこない
free(a);
free(a);
は二重解放しているように見えて合法だろ？
一度目のfreeでaにNULLが代入されて、二度目のfreeでは引数がNULLの場合はそのままreturnって処理されるんだから、理論上は何度free使ってもエラーにならないじゃないか
1009:デフォルトの名無しさん
21/08/24 19:58:14.02 Mn5s1DvN.net
何の話？ C？
1010:デフォルトの名無しさん
21/08/24 20:39:00.27 972JwtmU.net
>>980
>Rustで循環参照が起きるにはRc利用が必須
RcだけじゃなくRcとInterior Mutabilityが必須
(どちらか片方はmutableじゃないと循環させられないので)
>Weak(弱参照)を適切に上手く用いて循環参照を避けるのが大変な場合もあるが
Rustの場合は循環参照で意図通り動くコードを書くのに比べれば
弱参照に変更するのはすごく簡単
循環参照を修正してる例
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
1011:デフォルトの名無しさん
21/08/24 20:58:14.10 joymTvc2.net
すまんが、複数のファイルにソースを分割する練習教材みたいなものがあったら教えてくれんか？
1012:デフォルトの名無しさん
21/08/24 22:56:02.07 972JwtmU.net
次スレ
ｽﾚﾘﾝｸ(tech板)
1013:デフォルトの名無しさん
21/08/24 23:03:55.04 PednkAUi.net
>>992
「book」にもモジュールの章がある。
1014:デフォルトの名無しさん
21/08/24 23:31:00.93 OsSSnb/8.net
>>987
RcとRefCell使えば数行
1015:デフォルトの名無しさん
21/08/24 23:45:46.97 MkJE9y3A.net
循環によって現れるメモリリークは Rust が提供する「メモリ安全」を損なわないと定義されている。
Rust は循環参照を防がないし、メモリリークに対処するのはプログラマの責任。
1016:デフォルトの名無しさん
21/08/25 00:57:06.67 3XgQgETH.net
>>992
もう見てるかもだが
URLﾘﾝｸ(www.sheshbabu.com)
1017:デフォルトの名無しさん
21/08/25 01:28:54.33 6n+Di1sM.net
>>990
c
1018:デフォルトの名無しさん
21/08/25 01:29:12.12 6n+Di1sM.net
うんこ
1019:デフォルトの名無しさん
21/08/25 01:29:33.60 6n+Di1sM.net
1000ならここにいるやつら全員失職
1020:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 69日 1時間 5分 21秒
1021:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています