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/18(水) 10:49:15.04

>>672
自動的な参照外し(*を記載してないのに*適用)って、値を使うところで&Tや&&Tなどが使われたときにTの値になる、というルールだからそれも数学的でしょ。
あと&Tではない各種スマートポインタや自作の型を、*記載で参照外しする時も、Derefトレイト実装通りに行われるからこれも数学的。

**デフォルトの名無しさん** · 2021/08/18(水) 11:27:15.93

>>647氏が混乱したのもそこかもね
例えば
let a = 99;
let b = &a;
assert_eq!(100, b + 1);
assert_eq!(100, *b + 1);
つまり値を使う所では参照のままではなく安全に*が自動適用

構造体のフィールドアクセスも
struct Point {x: i32, y: i32}
let p = Point {x: 19, y: 31};
let q = &p;
assert_eq!(p.x, q.x);
assert_eq!(p.y, (*q).y);
つまりフィールドアクセスする所では参照のままではなく安全に*が自動適用
だからC言語などにある「q->y」という記法がRustには不要なので存在しない

**デフォルトの名無しさん** · 2021/08/18(水) 11:41:08.71

こじつけの自己レス自演が気持ち悪い
これでバレないとおもってるんだからww

お前も頑張って勉強中なの丸出しなのになぜそんなに上から目線で書きたがる？

**デフォルトの名無しさん** · 2021/08/18(水) 12:12:05.22

>>710
assert_eq!(100, b + 1);　は通るけど
assert_eq!(99, b);　はコンパイルエラーになるところがミソかな

**デフォルトの名無しさん** · 2021/08/18(水) 12:12:56.84

演算子も含めてメソッド呼出しのときの self の参照が調整されるのは言語コアの機能だけど
演算子の右辺で参照が剥がされるのは参照を受け取るバージョンのメソッドも用意されてるから
という理解でいいんだよね？

**デフォルトの名無しさん** · 2021/08/18(水) 12:16:13.67

>>710
>assert_eq!(100, b + 1);

`b + 1`のbは*が自動適用されてるわけじゃない

**デフォルトの名無しさん** · 2021/08/18(水) 12:52:27.85

そこはstd::ops::Addトレイトのimplがあるかどうか
ただしi32と&i32に対してはあるけど&&i32に対してはない
そのためさきほどの例だと
let a = 99;
let c = &&a;
assert_eq!(100, **c + 1); // i32はそのままOK
assert_eq!(100, *c + 1); // &i32は参照外してi32でOK
assert_eq!(100, c + 1); // &&i32のAddトレイト定義はないからコンパイルエラー

**デフォルトの名無しさん** · 2021/08/18(水) 13:56:40.85

繰り返し間違った内容垂れ流すのいい加減やめれ

**デフォルトの名無しさん** · 2021/08/18(水) 14:02:16.47

>>715で合ってるよ

**デフォルトの名無しさん** · 2021/08/18(水) 14:42:37.07

ご愁傷様

**デフォルトの名無しさん** · 2021/08/18(水) 15:05:20.49

ご安全に*

**デフォルトの名無しさん** · 2021/08/18(水) 19:37:59.33

質問したようなのと近い流れになってて助かった

(0..7).filter(|&x| x == 0);
↑これ通るから　↓こうしたら駄目だった。なんでなん？
let mut vec0 = vec![1, 2, 3, 4, 5, 6];
vec0.iter().filter(|&x| x == 1);

そこで、様々テストしたら、↓の方法でコンパイルが通ることがわかった
どのやり方が一般的なん？個人的には1か4かと思うんだけど。あと、2は+0することで型推論が働いてるのん？
vec0.iter().filter(|&x| *x == 1); //1
vec0.iter().filter(|&x| x + 0 == 1); //2
vec0.iter().filter(|&x| x == &1); //3
vec0.iter().filter(|&x| x.clone() == 1); //4
vec0.iter().filter(|x| **x == 1); //5
vec0.iter().filter(|x| *x == &1); //6

**デフォルトの名無しさん** · 2021/08/18(水) 19:43:27.81

全部結果まで含めて正しかった？

**デフォルトの名無しさん** · 2021/08/18(水) 19:48:58.01

ベクタの内容を↓にして
let mut vec0 = vec![1, 2, 1, 4, 1, 6];
1の数をcountするようにして表示させてみたけど、>>720の1～6のやり方でどれもcountの数は同じだね

**デフォルトの名無しさん** · 2021/08/18(水) 20:01:07.37

いいぞ！いいぞ！これも通るぞ！！

let mut test6 = vec0.iter().filter(|&&x| x == 1).count();
let mut test7 = vec0.iter().filter(|x| x == &&1).count();
let mut test8 = vec0.iter().filter(|x| *x + 0 == 1).count();

ヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノ

**デフォルトの名無しさん** · 2021/08/18(水) 20:03:48.63

Bible終えるのにどれぐらい時間かかりましたか？

**デフォルトの名無しさん** · 2021/08/18(水) 20:30:38.07

>>720
(0..7).filter(|&x| x == 0);と同等なのは
let v = vec![1,2,3,4,5,6];
v.into_iter().filter(|&x| x==0);

**デフォルトの名無しさん** · 2021/08/18(水) 20:47:56.15

>>725
うおー、まじか！
わかったありがとう。だからforループはちょっと違う挙動になるんだな

**デフォルトの名無しさん** · 2021/08/18(水) 21:38:07.08

違いをわかりやすく示すと
let vec0 = vec![1, 2, 3, 4, 5, 6];
assert_eq!(Some(&1), vec0.iter().next());
assert_eq!(Some(1), vec0.into_iter().next());

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

ありがとうありがとう
&TのイテレータとTのイテレータが別々になっているとはおもわなんだ

**デフォルトの名無しさん** · 2021/08/18(水) 21:54:22.03

まだ慣れてないからideに言われるがままに直してるな、、

**デフォルトの名無しさん** · 2021/08/18(水) 22:38:04.93

イテレータ回りはこのスライドが良いと思ったけど多少基礎知識ないときついかもしれんな
https://speakerdeck.com/optim/domination-of-the-rust-iterators

**デフォルトの名無しさん** · 2021/08/18(水) 23:13:44.45

>>728
そう考えるよりもムーブor借用と捉えるほうがいいかな
vec0.into_iter()だとムーブになるから値そのものが次々と来る。しかしその後にvec0は使えない。
vec0.iter()だと借用になるから値への参照が次々と来る。その後もvec0は使える。
(&vec0).into_iter()でも借用になるから値への参照が次々と来る。その後もvec0は使える。

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

この2つは何が違うんですか？

演算子?
https://tourofrust.com/38_ja.html
unwrap
https://tourofrust.com/39_ja.html

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/19(木) 02:52:20.85

>>732
これは例がよくないな。
もう一段ほど関数呼出しを挟む構造になっていればより分かり易くなる気がする。

? 演算子はエラーだったときにそのエラー値を返り値として return する。
つまりその例の場合は do_something_that_might_fail が
エラー値を返したときは main から抜ける。
関数がエラーを出したときに上位にもエラーとして伝播させる機能。

unwrap は Result を剥がすが、エラー値だったときにはその場で panic する。
unwrap を書くというのは「エラー値が返されることはないことをプログラマとして保証する」
または「そのエラーに対して対処する方法はない、対処する気はない」という表明で、
assert 的な意味合いを含む。
エラーの対処を書くのが面倒だけど Result を剥がして型は合わせないといけない
というときに雑に unwrap することはあるんだけど、
多少なりとも汎用的なライブラリにするなら (事前条件が正しい限り) panic が
起こるのは好ましくはないので使い方は慎重に。

**デフォルトの名無しさん** · 2021/08/19(木) 03:04:22.69

>>732
?演算子はほぼtry!マクロのsyntax sugar
言語自体に組み込んだ時にその適用範囲を広げた

try!マクロとは見やすく省略して書くと
Result型rに対してはtry!(r)がほぼmatch r { Ok(n) => n, Err(e) => return Err(e) }となる

つまり?演算子はOption型やResult型の尻につけてNoneやErrの時にreturnする
一方でunwrapはpanicして死ぬ

**デフォルトの名無しさん** · 2021/08/19(木) 06:51:23.03

ほぉ、なるへそ
noneとかへの振る舞いの遅延行為としての?op
ある関数を呼んだ関数自体でerrへの振る舞い決定すべきだと考えた場合は?opにする
とすると?op含んだ関数のcallerはmatchとかのタイプ別振る舞い定義をちょっとやかましめ書く必要ありだな

いまいちpanicの振る舞いが分からん
spawned threadが内部でパニくった場合その娘、息子スレッド（スレッドの下層スレッド）とそのスレッド自体にのみunwindが適用されるんだよな？(´・ω・｀)

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

何でやねん(笑)

**デフォルトの名無しさん** · 2021/08/19(木) 12:31:22.21

vec0.iter().filter(|&x| x == &1);
これの数字に&つけて型同じにしたら通るってのが納得できないな～
比較がプリミティブ型の変数同士だったら自動的に数値として扱って欲しい

**デフォルトの名無しさん** · 2021/08/19(木) 13:09:24.52

>>737
それは強い静的型付けのメリット
異なる型同士の==が通るのは困る

といいたいところだけど
PartialEqトレイト次第で異なる型でも==してくれる場合もある
文字列など
でも整数は厳密でi32とi16ですら不許可

**デフォルトの名無しさん** · 2021/08/19(木) 13:34:53.71

>>738
でも、上の例で
vec0.iter().filter(|&x| x + 0 == 1);
が通るのは+0したときに中身がプリミティブ型だから数値だけ取り出してくれてるんでそ？

**デフォルトの名無しさん** · 2021/08/19(木) 13:41:52.67

>>739
それはまた別で>>715
つまり足し算の実装

**デフォルトの名無しさん** · 2021/08/19(木) 14:53:02.41

&i32 + i32 の計算ができるようAddトレイトで実装されていて、結果をi32で返すようになってるからエラーにならないってことでしょ？

**デフォルトの名無しさん** · 2021/08/19(木) 14:59:15.22

>>741
そのとぉーり！

**デフォルトの名無しさん** · 2021/08/19(木) 15:34:51.11

>>741
ご丁寧にi32+i32 i32+&i32 &i32+i32 &i32+&i32の4種類をカバーしてくれてるね
&&i32はサポートしていないため
vec0.iter().filter(|x| x+1==2)はコンパイルエラー

**デフォルトの名無しさん** · 2021/08/19(木) 16:37:43.70

まず>>715の間違いを反省しようね

>let a = 99;
>let c = &&a;
>assert_eq!(100, *c + 1); // &i32は参照外してi32でOK

**デフォルトの名無しさん** · 2021/08/19(木) 16:44:47.80

>>744
それであってるぜ
&i32+i32は左だけ参照を外してi32にして足し算する

**デフォルトの名無しさん** · 2021/08/19(木) 17:44:32.43

そりゃ当たり前だろw
とことんダメなやつだな

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

>>733
>>734
丁寧に教えてくれて、ほんとありがとう

**デフォルトの名無しさん** · 2021/08/19(木) 21:41:29.08

>>743
なるほど、なんかすべての挙動を把握しないとならないんだね
でも、やっぱり「&1」が通用するのは納得いかない(´･ω･`)

**デフォルトの名無しさん** · 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()無いの？