Rust part11

**デフォルトの名無しさん** · 2021/06/17(木) 00:24:12.56

公式
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/

**デフォルトの名無しさん** · 2021/08/19(木) 22:05:30.35

>>748
基本的には正しく型を用いれば済む
&i32は数値ではなく数値への参照にすぎない
*付けなくても済む便宜の恩恵を受けるのはよいけどそれを理解したうえでしているかどうかの違い

**デフォルトの名無しさん** · 2021/08/19(木) 22:29:20.97

String と &str が == で比較できるなら i32 と &i32 も比較できて良い気はする
単に impl がないだけだから pull req 送ったら取り込んで貰えるのでは

**デフォルトの名無しさん** · 2021/08/19(木) 22:55:59.39

もう純粋に&1て、1の参照じゃんね
その意味がわからんし、存在意義がわからん
変数同士ならわかるけど、定数的に書いてるんだったらもうプリミティブ型だったら
中身で判断してくれよヽ(`Д´)ﾉｳﾜｧｧｧﾝ

**デフォルトの名無しさん** · 2021/08/19(木) 23:28:13.13

>>750
今もi32と&i32の組み合わせ4通り定義
そこへ&&i32が加わると9通り定義
そこまでする意義は？

>>751
だからx==&1ではなくて素直に*x==1と書こう

**デフォルトの名無しさん** · 2021/08/19(木) 23:48:19.67

>>751
プリミティブのwrapper crateを作って自分の好きなように定義すれば万事解決

**デフォルトの名無しさん** · 2021/08/19(木) 23:58:39.37

そういや&1みたいなのって実際に使う場面あるの？

**デフォルトの名無しさん** · 2021/08/20(金) 00:03:22.90

推奨する方法をやりやすく、推奨しない方法をやりにくく
Rustは他の言語に比べると特に後者についてよく考えられてる

**デフォルトの名無しさん** · 2021/08/20(金) 00:07:53.98

>>754
postgresクレートのquery()でparamsに数字を書きたいときとか

pub fn query<T>(&mut self, query: &T, params: &[&(dyn ToSql + Sync)]) -> Result<Vec<Row>, Error>
where
T: ?Sized + ToStatement

**デフォルトの名無しさん** · 2021/08/20(金) 01:09:30.92

>>752
*x == 1 と書けというのは分かるんだけど
impl PartialEq<String> for &str や impl Add<&i32> for i32 があるのに
impl PartialEq<&i32> for i32がないのは一貫性がないように思う
なんで実装されていないのだろうか

**デフォルトの名無しさん** · 2021/08/20(金) 01:11:40.00

>>757
自己解決
RFC1332で議論されていた

**デフォルトの名無しさん** · 2021/08/20(金) 01:12:10.07

rubyもpythonも見よう見まねで書けるんだけどなー
javaなんてC++とほとんど同じだから半日もあればマスターできる

でもrustだけは勉強しないと無理っぽい
難しいよ

**デフォルトの名無しさん** · 2021/08/20(金) 01:34:49.41

>>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, });

**デフォルトの名無しさん** · 2021/08/20(金) 01:38:48.16

オブジェクトの同一性 (メモリ上の同一の場所に配置されている) を判定したいときって
参照を == で比較しても駄目ですよね？
ポインタを取り出すのも恰好が悪いように思うんですが、
なんか定番の方法ってあります？

**デフォルトの名無しさん** · 2021/08/20(金) 01:44:35.28

>>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 が出てきてしまう

**デフォルトの名無しさん** · 2021/08/20(金) 01:55:55.02

>>761
Rustは所有権があるから同一メモリを指すのは所有権を持つものへの参照同士かな
つまりコード上明白であり比較する必要性がないことに？

**デフォルトの名無しさん** · 2021/08/20(金) 02:30:09.57

こういうことかな
複数の参照も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

**デフォルトの名無しさん** · 2021/08/20(金) 02:32:13.12

ptr::eqで

**デフォルトの名無しさん** · 2021/08/20(金) 10:16:46.67

メンテナンス性最悪の自己満足オナニー言語

**デフォルトの名無しさん** · 2021/08/20(金) 11:41:07.99

>>766
それは逆
メンテナンス性は最も優れているプログラミング言語の一つ

**デフォルトの名無しさん** · 2021/08/20(金) 13:42:55.60

ポインタ関連の問題が所有権と参照で絶対に発生しないってのはデカイよね

**デフォルトの名無しさん** · 2021/08/20(金) 13:59:09.33

将来の苦痛を先に解消できるのが良いのにな、不具合も絞り込みやすい
メンテナンス性悪いってどの辺言ってんのか聞いてみたい

**デフォルトの名無しさん** · 2021/08/20(金) 14:18:54.33

一年ぶりに触るソースを大規模改修しても、コンパイル通せばほぼ動く安心感ある
他言語（特に動的型言語）だと相当テストを作り込まない限り、このメンテナンス性は得られない印象

**デフォルトの名無しさん** · 2021/08/20(金) 14:28:37.40

データ設計を少し考えさせられることによって
メモリ安全性を得ただけでなく見通しも良くなったｗ

**デフォルトの名無しさん** · 2021/08/20(金) 15:07:52.58

潜在的にバグの原因となる変数の扱いすると
コンパイラが怒るのは安心できる

**デフォルトの名無しさん** · 2021/08/20(金) 15:24:51.42

>>768
絶対に発生しないは言い過ぎ

**デフォルトの名無しさん** · 2021/08/20(金) 15:31:54.88

繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。。
そして文字列が複数あったり、更にそれをマクロにされると、それで書き直しが必要だったり
多くの言語でも初心者と上級者で当然、コードの美麗さに違いが出るが余りにも差があり過ぎ
たった「一年ぶり」でコンパイルが通らない言語なんてあるだろうけど、そんな話じゃない

**デフォルトの名無しさん** · 2021/08/20(金) 16:06:16.17

イテレータなんてどの言語にもあるし困るようなことか？
無理やり導入で汚い言語よりもRustは綺麗に洗練されていて書きやすい

**デフォルトの名無しさん** · 2021/08/20(金) 16:12:21.41

同じようなことなのに人によって書き方が全然違うからクソって言いたいんじゃないの？

**デフォルトの名無しさん** · 2021/08/20(金) 17:10:02.79

何が何故問題なのか説明できないイチャモンなんかほっとけ

**デフォルトの名無しさん** · 2021/08/20(金) 20:06:41.30

文字列が複数種類あることが嬉しい人のための言語
嬉しくない人は別の言語を使うべき

**デフォルトの名無しさん** · 2021/08/20(金) 20:28:27.92

>>778
例えばいわゆるスクリプト言語などはいずれもRustのString型相当のものしかないため非効率でメモリ食い散らかす状態になっていますね
Rustはそれに加えて部分を指し示すだけの文字列スライス&str型を持っているので無駄なアロケーションを防いで効率の良いコードを書けるようになっていますね

**デフォルトの名無しさん** · 2021/08/20(金) 21:05:31.52

>>774
> 繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。

あなたはちょっと無知すぎます。
まず高階関数とも言われるmap()やfilter()等を用いるにはイテレータが必須ですから同じことを指しています。
どちらかを選ぶようなものではありません。

次にRustのforループもイテレータ必須で内部でイテレータを作ってforループを回していますから同じことです。
forループ方式と高階関数方式の2種類で書けてしまうじゃないか！と言いたいのでしょうが、これは他のプログラミング言語でも同じで2種類あります。

**デフォルトの名無しさん** · 2021/08/20(金) 21:07:42.14

内包表記なる書き方がある言語もあるらしいねｗ

**デフォルトの名無しさん** · 2021/08/20(金) 21:38:29.08

繰り返しでiter()を使ったりinto_iter()を使ったりと複数のやり方があるのはおかしいとの御指摘だが
into_iter()は値のイテレータ
iter()は参照のイテレータ
同じものに対して適用しても別のイテレータが得られる

**デフォルトの名無しさん** · 2021/08/20(金) 21:47:24.73

少し前までは荒らし以外は結構いいスレだったが
近頃はC++スレでダベってた暇人たちが引っ越して来ちゃってゴミスレ化しつつあるね

**デフォルトの名無しさん** · 2021/08/20(金) 22:24:24.81

>>782
これ、同じメソッドにするのではなくて、イテレータにするのはiter()で共通にして、
参照する場合には、別のメソッドにしたほうがいいんじゃないのかなと思う

例えば
iter()　←　値
iter().ref()　←　参照
とか

**デフォルトの名無しさん** · 2021/08/20(金) 22:50:20.88

なんで配列にイテレータないんや！
配列を使うな！ vecを使えということなのか

そういえばC++でもvector使えとか言われてたな
もっと配列にも愛を！

ところでvecより配列の方がうれしいことってある？
実は配列いらない子なんじゃないかと思い始めた

**デフォルトの名無しさん** · 2021/08/20(金) 23:02:42.83

>>784
それはiterのシグネチャがメソッドチェーンするかどうかで変わってしまうから
今のRustの型システムでは表現不能だと思う
プログラマ視点でも、後続する関数呼び出しがその手前に影響するってのはかなりわかりにくいのでは？

**デフォルトの名無しさん** · 2021/08/20(金) 23:22:41.88

>>785
スタックとかヒープとかアロケーションとか気にならない用途ならRust使わなくてもいいと思うの

**デフォルトの名無しさん** · 2021/08/20(金) 23:47:01.90

>>786
moveをデフォルトにするのは無理だけど
iter()は参照でiter().into()で値ならCow的なのでなんとかなる気がする

**デフォルトの名無しさん** · 2021/08/20(金) 23:47:19.51

>>785
> Rust 1.53からは配列型に対して直接IntoIteratorトレイトが実装されるようになり、配列をそのままループに使うことが出来るようになりました。
https://tech-blog.optim.co.jp/entry/2021/06/18/080000

**デフォルトの名無しさん** · 2021/08/20(金) 23:54:51.56

>>787
いやいや、もちろん配列との比較なんだから、アロケーションの発生しない処理の話だよ
スタックを気にするなら、むしろヒープに置いた方がいいし
(キャッシュミスヒットの話じゃなくて、スタックオーバーフローの話ね)

**デフォルトの名無しさん** · 2021/08/20(金) 23:55:03.84

>>788
それだとinto_iterとは意味変わっちゃってるのでは
intoで元のコレクションのコピーが作られて、それをイテレートするってことでしょ？
コピーを作らず所有権を奪って値をイテレートする方法がなくなってしまう

**デフォルトの名無しさん** · 2021/08/20(金) 23:56:59.11

>>789

おお！　知らなかった。
ってかめっちゃ最近じゃん！
追いかけるの大変だな

**デフォルトの名無しさん** · 2021/08/21(土) 01:58:33.16

>>784
iter().cloned() とか使えば良いのでは

**デフォルトの名無しさん** · 2021/08/21(土) 05:48:08.14

hoge.iter()だと参照でhoge.iter().fuga()だとhogeの所有権ぶんどる、みたいなのは無理な気がする

**デフォルトの名無しさん** · 2021/08/21(土) 06:24:06.23

>>790
Vecは可変長なので必ずヒープからアロケーションが発生します
一方で配列は必ず固定長でスタックに置かれます

>>784
(&vec0).into_iter()はvec0.iter()となるので
into_iter()だけにすることも出来なくはないと思いますが
書き方が面倒なので簡潔なiter()と共存してるのだと思います

**デフォルトの名無しさん** · 2021/08/21(土) 09:34:58.66

>>791
Cow使えばできるという話じゃないよ
lazyに所有権を取得するような機能を持った型を追加すれば
今の型システムでも表現できないってことはないんじゃないかって話

そういう型を追加することを型システムの変更と言うのであれば
今の型システムでは表現できないてのに同意するよ

**デフォルトの名無しさん** · 2021/08/21(土) 09:43:26.29

>>795
アロケーションが発生するのは伸長するときだけでしょ
伸長するような用途だったら、そもそも配列使えないし

>一方で配列は必ず固定長でスタックに置かれます
だめじゃん。スタックオーバーフロー考慮するならvecの方がいいじゃん

まあ、自分も組み込み以外でスタックフレームのサイズなんて考慮したことないけど

**デフォルトの名無しさん** · 2021/08/21(土) 09:50:40.59

>>795
ちなみにスタックにあることによってL2キャッシュに載りやすいだろ！
という意見ならそれは同意する。サイズが小さければね。

**デフォルトの名無しさん** · 2021/08/21(土) 10:08:08.47

>>797
> アロケーションが発生するのは伸長するときだけでしょ

いいえ。
Vecの実体は必ずヒープにアロケーションされます。
Vec自体は(指定しなければ)スタック上で、ヒープへのポインタや長さなどで構成されて固定長です。
Stringも内部はVec<u8>なので同様です。

**デフォルトの名無しさん** · 2021/08/21(土) 10:12:53.88

>>799
ああ、アロケーションじゃなくてヒープにってところを問題視してる？
ガベージコレクションの発生を懸念してる？

**デフォルトの名無しさん** · 2021/08/21(土) 10:22:22.66

>>800
Rustではガベージコレクションは起きない
しかしスタック上かヒープ上かの区別は重要
スタック上のデータはその関数を終える時に消滅する

**デフォルトの名無しさん** · 2021/08/21(土) 10:31:43.28

>>801
>Rustではガベージコレクションは起きない
ヒープを使ってるんだから起きないわけないだろ

＞スタック上のデータはその関数を終える時に消滅する
Vecの中身だって関数を終えるときに解放されるでしょ
されないんだっけ？

そもそもの話は配列を使ってるところをVecにしても問題なくね？ってことなんだけど
どこが問題になるかの例を示してもらえたら、わかりやすい

**デフォルトの名無しさん** · 2021/08/21(土) 10:58:14.92

rustにはガベージコレクションがないんだぜ・・・

**デフォルトの名無しさん** · 2021/08/21(土) 11:04:35.75

デストラクタ的な機構で後始末するのはガベージコレクションとは普通言わない

**デフォルトの名無しさん** · 2021/08/21(土) 11:09:11.24

Cでもひーぷをつかうとがべーじこれくしょんがおきるの？

**デフォルトの名無しさん** · 2021/08/21(土) 11:11:34.22

ヒープへのメモリアロケーションはコストが高いから避けたいんでしょ

**デフォルトの名無しさん** · 2021/08/21(土) 11:25:28.41

>>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]

**デフォルトの名無しさん** · 2021/08/21(土) 11:42:53.96

そういや何でalloca()無いの？

**デフォルトの名無しさん** · 2021/08/21(土) 12:23:12.36

>>795
Box<[T; N]> のように配列がヒープに置かれる場合もある

**デフォルトの名無しさん** · 2021/08/21(土) 12:35:23.13

>>809
それはBoxだからであって、そんなこと言い出したら整数だってヒープに置かれうる
しかし普通に「整数型はスタックに置かれる」と言われる時は、Boxを使わない場合を意味している
Boxを使えばヒープに置かれるのは自明だからだ

したがって、整数や配列やVecの管理データ部分はそのままだとスタックに置かれるがVecのデータ実体は常にヒープに置かれる、で良い

**デフォルトの名無しさん** · 2021/08/21(土) 13:25:00.39

うーん、なんだかなー
みんなヒープのことを無限にバイトを吐き出す魔法の箱かなんかだと思ってない？

>>805
>Cでもひーぷをつかうとがべーじこれくしょんがおきるの？

当然
Cのmalloc/freeやC++のnew/deleteでもガベージコレクションは発生する
wikipediaの「ヒープ領域」がよくまとってるよ

いくつかの理由からfree/deleteのガベージコレクションはJavaやC#のガベージコレクションよりも超高速だ
それでも、組み込みの世界ではガベージコレクションのせいでリアルタイム性が失われることを嫌がって、
ヒープを使わなかったりする

じゃあ、組み込みでは動的なメモリをどうするかっていうと、リンクドリストのノードをメモリブロックに
見立てて、メモリ管理システムにしたりする
これだと取得も解放も定数時間のコストだからね

>>807
すまん、例をみてますます配列なくても困らない気がしてきた
配列でできて、Vecにできないことはないの？

**デフォルトの名無しさん** · 2021/08/21(土) 13:35:03.05

>>811
Rustにはガベージコレクションはありません
おっしゃる通りヒープからの取得も解放も定数時間のコストで行なわれ更にガベージが溜まることはありません
Rustでは生存期間や所有権に貸し借りが明白になっているため、使用中のものが解放されたり、解放済みが使われたり、使用済みが解放されなかったりは起きません

**デフォルトの名無しさん** · 2021/08/21(土) 13:50:09.86

>>812
>ヒープからの取得も解放も定数時間のコストで行なわれ
これってどういう原理？　本当に定数ならそれもうヒープじゃないんじゃ

ヒープツリーを辿る処理も未使用ノードを結合する処理も定数時間って
ありえないと思うんだけど

**デフォルトの名無しさん** · 2021/08/21(土) 14:16:15.10

もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
そのためRustにガベージコレクションがないことを理解できていないような感じ？

**デフォルトの名無しさん** · 2021/08/21(土) 14:22:08.01

調べた
・rustのヒープはフリーリストアロケータじゃない
（サイズごとのメモリスラブをさらに分割して使う）
・取得・解放は定数時間じゃない
(メモリスラブ全体が未使用になったときに、デフラグして別サイズのスラブとして利用可能になる)
→これ実質ガベージコレクション処理じゃん
・当然デフラグは発生するが、大して問題にならない
→そうだろうね。C++でさえアロケータ書いたことない
・問題になるならアロケータを自作することも可能(デフォルトはjemalloc)
だそうだ。
ヒープはヒープ構造じゃないのか……

**デフォルトの名無しさん** · 2021/08/21(土) 14:36:21.13

>>814
>もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
freeの中にもガベージコレクション処理があるんだよという話
javaと違ってマーク＆スイープ処理いらないから早いけどね

>そのためRustにガベージコレクションがないことを理解できていないような感じ？
そんなことはわかってる
今は処理コストの話をしてる

サイズが変わらないVecと配列(配列なのでもちろん固定長)でそこまで優位の差があるのかと訊いた
そこでVecはヒープを使う(からダメだ)という答えが返ってきたので、
ヒープを使うとなぜダメなんだ？　ガベージコレクションのオーバーヘッドを気にしてるのか？と

そうするとrustはガベージコレクションありませんと言われた
じゃあ、結局のところヒープを使うとなぜダメなんだ？

**デフォルトの名無しさん** · 2021/08/21(土) 14:43:58.08

勝手に定義した「ガベージコレクション」なんか議論するだけ時間の無駄

**デフォルトの名無しさん** · 2021/08/21(土) 14:48:02.99

>>816
あなたが完全に間違っている
それを世間ではガベージコレクションとは呼ばない

**デフォルトの名無しさん** · 2021/08/21(土) 14:50:34.09

>>818
辞書が絶対とは言いたくないがwikipediaの「ヒープ領域」見て

**デフォルトの名無しさん** · 2021/08/21(土) 14:52:48.65

自分でfreeしたものをGCと呼ぶとは強者が現れたな

**デフォルトの名無しさん** · 2021/08/21(土) 14:53:06.41

それこそwikipediaの「ガベージコレクション」見てもらった方がいいのでは。

**デフォルトの名無しさん** · 2021/08/21(土) 14:53:37.02

もうジェマロクはデフォルトじゃないよ

**デフォルトの名無しさん** · 2021/08/21(土) 14:58:27.12

そういやこんな記事があったよ

実装言語を「Go」から「Rust」に変更、ゲーマー向けチャットアプリ「Discord」の課題とは
ttps://atmarkit.itmedia.co.jp/ait/articles/2002/10/news038.html

> 平均すれば高速に動作していたものの、数分ごとに平均応答時間が急に大きくなり、
> ユーザーエクスペリエンスを損なっていた。調査したところ、
> これはGoの中核機能であるメモリモデルとガベージコレクタ（GC）に起因することが分かった。

> Rustではガベージコレクションが不要だ。
> 同社がRead StatesサービスをRustで実装しようと考えたのはこれが理由だ。
> Rustを使えば、Goで実装した場合に生じた平均応答時間の急増は見られないだろう。

**デフォルトの名無しさん** · 2021/08/21(土) 15:02:21.85

>>820
だから、ここではコストの話をしてるんだって言ってんのに

>>821
見た。もちろん知ってる。
本題からずれてる。自動解放とかデフラグの定義の話がしたいんじゃない
配列とVecのことが知りたいんだって

なんだってこう話を逸らすんだ？

**デフォルトの名無しさん** · 2021/08/21(土) 15:02:56.01

>>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の版で消させていただきました
せやな。

**デフォルトの名無しさん** · 2021/08/21(土) 15:10:24.32

>>824
まずはプログラミング言語におけるガベージコレクションとは何かを理解して
次にRustではそのガベージコレクションがないことを理解して
その上で何を質問したいのかを整理してはいかがでしょうか？
それを終えてからでないとあなただけ用語の定義が異なったままでは話が進みません

**デフォルトの名無しさん** · 2021/08/21(土) 15:10:57.04

ガベコレは普通javaとかpyのコンパイラやらインタプリタがreference counterをオブジェクトに勝手に付随させる事を想定するけどな

Vec arr処理コストの違いに関してはbuffer使わないんだからarrayの方が基本的には糞みたいに早いと思うがな
そこらosとかによって最適化図られるからオブジェクト生成のとき以外は決定的な違いあんまなさそうだが
要素数をコンパイルタイムに決定(これのアルゴにもよるが)出来るなら普通はシンプル配列の方が速いよね

goはparallel threadingみたいな部分で変なgc実装してて大量に独立の計算量ハード問題導入するからねそこらへんがドイヒーなんだろうな
俺は好きだけど(´・ω・｀)

**デフォルトの名無しさん** · 2021/08/21(土) 16:18:04.16

>>824
何度も説明されている通り
配列は固定長なのでデータ管理部分はなく配列は通常スタック上
Vecは可変長なのでデータ管理部分がありそれは通常スタック上そして配列相当部分は常にヒープ上

**デフォルトの名無しさん** · 2021/08/21(土) 16:29:59.01

コンパクションとガベージコレクションの区別がついてない

世の中のガベージコレクターがコンパクションもやってるからといって
コンパクションのみを指してガベージコレクションとは呼ばない

**デフォルトの名無しさん** · 2021/08/21(土) 16:33:27.85

ふりだしに戻る >>787

**デフォルトの名無しさん** · 2021/08/21(土) 16:37:39.49

>>828
それの何が問題？
stringの実装はヒープだけど問題ないよね？
こういう使い方をすると配列より100倍くらい遅いとか、メモリリークするからVec止めて配列使えとか
そういう注意点ある？

もちろんループの中でVec::newするとオーバーヘッドでかいとか、
そういうわざとらしいのはなしにして

あえていうなら初期化の記述量がちょっと増える、とか？

**デフォルトの名無しさん** · 2021/08/21(土) 16:59:15.86

>>831
誰も何も問題にしていませんよ
あなたが勘違いをして勝手な何かを問題にしているだけ
StringはVecにstructの皮を被せただけなので状況は同じ

**デフォルトの名無しさん** · 2021/08/21(土) 17:06:03.36

>>829
HDDの頃はよく使ってたHDD最適化と容量を増やすみたいなソフトを思い出した

HDDのデフラグ　→　メモリコンパクション
HDDにある不要なキャッシュの削除　→　ガベージコレクション

こんな感じに似てるな

**デフォルトの名無しさん** · 2021/08/21(土) 17:16:16.64

ヒープがヒープ構造じゃないのかとか言ってるから本当に何も知らなかったのだろう
オレオレ用語使われると混乱するからとりあえずmalloc動画くらいみて勉強してきてほしい

**デフォルトの名無しさん** · 2021/08/21(土) 17:26:30.08

>>834
そこ話の本筋じゃないんだよなー
Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー

**デフォルトの名無しさん** · 2021/08/21(土) 17:30:07.73

>>835
ヒープ使ってるからダメ、なんて誰も言っていない
全ては君の勘違い

**デフォルトの名無しさん** · 2021/08/21(土) 17:31:33.62

>>836
そうなの？　じゃあ結論として配列はVecに置き換えても問題ないってこと？

**デフォルトの名無しさん** · 2021/08/21(土) 17:52:04.92

Vecは固定長配列(型[u8; 32]とかで表されるやつ)を置き換える用途としては使えないが, 逆に言えばそれだけ

**デフォルトの名無しさん** · 2021/08/21(土) 18:26:53.45

むしろ配列なんてクレート使わないとコンパイル時点で数値が決まってないと使えないから
ほとんど出番がないんだから、どこに悩む必要があるというのか

**デフォルトの名無しさん** · 2021/08/21(土) 18:30:22.30

>>835
＞Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー

あなたの妄想ではないですか？
スレを読みましたが、
Vecはヒープ使ってるからダメと言われた書き込みが見当たりません。

**デフォルトの名無しさん** · 2021/08/21(土) 18:31:04.95

ヒープは悪であるということをハッキリと言う

**デフォルトの名無しさん** · 2021/08/21(土) 18:41:19.82

Linux のデフォルトではスタックの大きさは 8 メガが上限じゃなかったっけ？
(Windows だともっと小さかったはず)
大きさが固定 (コンパイル時に確定する) でかつ十分に小さく寿命が短いなら配列をスタックにおく
のは性能的に有利 (確保と解放のコストが小さい) だが、大きさを見積もれないときにスタックに置くと
スタックが足りないときにどうにもできないで即死するしかない。

大きさのわからない配列はスタックに置くべきではないというのが世の常識というもの。
少なくとも高レイヤのアプリケーションでは。

**デフォルトの名無しさん** · 2021/08/21(土) 20:16:15.20

仮想メモリなんだからスタック8GBに設定すればいいんじゃないの？

**デフォルトの名無しさん** · 2021/08/21(土) 20:43:23.20

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ
ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/21(土) 20:47:51.35

Nimは知らんがパイソンが読みやすいなんて

**デフォルトの名無しさん** · 2021/08/21(土) 20:53:42.26

pythonが特別読みやすいとは思わんが、pythonで読みづらいコード書くやつが
何で実装しても読みやすいものを書くことはないだろう。

**デフォルトの名無しさん** · 2021/08/21(土) 20:55:25.62

>>844
Pythonはたまたま外部ライブラリ充実などで普及していますが、あまりよろしくない言語です。
そのためPythonで開発したいという人はいないです。
なので「Pythonのような高い可読性を実現している」と宣伝されても逆効果。

**デフォルトの名無しさん** · 2021/08/21(土) 20:58:33.68

>>844の人は関係ないスレに迷惑かけて、nimユーザーのイメージダウンが目的なんだろうか。