Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

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

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

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

※次スレは原則>>980が立てること

前スレ
Rust part12
https://mevius.5ch.net/test/read.cgi/tech/1629813327/

**デフォルトの名無しさん** · 2021/11/07(日) 10:05:36.56

Rust The Book (日本語版)
https://doc.rust-jp.rs/book-ja/
Rust edition guide (日本語版)
https://doc.rust-jp.rs/edition-guide/
Rust by example (日本語版)
https://doc.rust-jp.rs/rust-by-example-ja/
Rust cookbook (日本語版)
https://uma0317.github.io/rust-cookbook-ja/
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
Rust nomicon book (日本語版)
https://doc.rust-jp.rs/rust-nomicon-ja/
Rust WASM book (日本語版)
https://moshg.github.io/rustwasm-book-ja/
Rust embeded book (日本語版)
https://tomoyuki-nakabayashi.github.io/book/
Rust enbeded discovery (日本語版)
https://tomoyuki-nakabayashi.github.io/discovery/

**デフォルトの名無しさん** · 2021/11/07(日) 10:06:41.30

Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust async-std Book
https://book.async.rs/
Rust The Unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
The Rust Reference
https://doc.rust-lang.org/reference/
The Rust Standard Library
https://doc.rust-lang.org/std/

**デフォルトの名無しさん** · 2021/11/07(日) 12:23:40.47

乙
シャドーイングが困るのって関数がよっぽど長いときだけなんで問題にならんよね

**デフォルトの名無しさん** · 2021/11/07(日) 13:02:12.62

＞前スレの質問「間違って同じ変数名つけたコード片突っ込んでしまった系だと他言語にあるらしい２重宣言エラーないの怖くないですか？」

他の言語でもスコープが違えば二重宣言エラーになりません
つまり他の言語でも意図しない同名変数ミスは同じように起き得ます
例えば以下はC言語の例

int c = 100;
int main() {
　int c = 200;
　{
　　int c = 300;
　}
　printf("%d\n", c); /* コンパイルは通って 200 となる */
}

Rustのシャドーイングは同じブロックスコープでも同名変数が通りますが
仮にミスで同名変数を付けたコードを挿入してしまったとしても
・その時点で先行の変数が既にライフタイム尽きていれば影響ゼロ
・その時点で先行の変数のライフタイムがあって割り込む形になる場合
　　・それ以降で二度の消費が発生して借用エラー発生となる可能性が高い
　　・先行の変数が一度も使われていない段階なら未使用warning発生
　　・型が違っていれば割り込む形であっても型違いでエラー発生
と影響ゼロもしくは引っかかる可能性が高いでしょう

>>4
おっしゃる通り、そもそも意図しない同名変数に気付かない時点で「その関数は長すぎ」ですね

**デフォルトの名無しさん** · 2021/11/07(日) 13:03:26.24

ある値をちょっとだけ処理したものにどんな名前を付けたいかってのは、
まあ適した名前があるならそれに越したことは無いけど
同じ名前を付けることによってたいした違いはない、かつ以前の値にアクセスすることはもうないことが明示できるので
それはそれで使いようはあるよ。

以前の値にアクセスしないという意思を持ってシャドーイングを使うのでそれで困ることはない。
うっかりで同じ名前を付けてしまった場合も大抵の場合は型の違いとかで検出されるし。

**デフォルトの名無しさん** · 2021/11/07(日) 14:26:48.84

何を問題にしてるのか分からんけど、コンパイラから見たら、同じ変数名宣言でも連番で構文解析しているわけで
ブロックスコープによりシャドーされても何ら関係ないが、インライン展開して最適化するrustコードだと問題が
出る場合もありうる。それとシャドーと以前の値にアクセスすることはもうない事は意味が違う

**デフォルトの名無しさん** · 2021/11/07(日) 14:35:43.57

>>7
間接的にアクセスしうるとかいうのはもちろんあるけど、
あくまでもプログラマが読み書きする上での意図として明示するという意味ね。
実際にもう (直接には) 使えないんだから使えないという意味だよ。

**デフォルトの名無しさん** · 2021/11/07(日) 14:45:10.83

ん？まあありうるだろうけど、そんな意図を持ってシャドーイングをするコードは捨てろよ？明示じゃねーわ

**デフォルトの名無しさん** · 2021/11/07(日) 15:07:42.51

そうか。

**デフォルトの名無しさん** · 2021/11/07(日) 15:10:45.19

>>996
C/C++だとスコープ中で外のスコープの宣言と被ってたら警告出るよね

**デフォルトの名無しさん** · 2021/11/07(日) 15:27:52.97

>>7
＞それとシャドーと以前の値にアクセスすることはもうない事は意味が違う

それはシャドーされてもスコープ終了と異なり、尽きてなければライフライムは残ってるという話だよね？
例えば
let mut a = vec![1,2,3];
let b = &mut a;
let a = [4,5,6];
b.extend(a);
assert_eq!(b, &[1, 2, 3, 4, 5, 6]);

>>11
被ってるCのコード>>5を今gcc test.cしたけどその警告出ない

**デフォルトの名無しさん** · 2021/11/07(日) 16:09:12.89

おま環

**デフォルトの名無しさん** · 2021/11/07(日) 16:58:36.83

intellijでも、シャドーイングがあったときは警告出てなかったっけ？

**デフォルトの名無しさん** · 2021/11/07(日) 17:10:25.95

変数名にシャドーイングって含めとけばいいのでは

**デフォルトの名無しさん** · 2021/11/07(日) 17:23:30.13

そんなことよりもだ！Rustに限らないけど
これって誰も食いつかないんだけど、１と２どっちが良いか、そろそろ決着つけてくれ
let upper = 1000;
// １、これと
let mut acc = 0;
for n in 0.. {
　　let n_squared = n * n;
　　if n_squared >= upper {
　　　　break;
　　} else if n_squared % 2 == 1 {
　　　　acc += n_squared;
　　}
}

// ２、これ
let acc1: u32 = (0..).map(|n| n * n)
　.take_while(|&n_squared| n_squared < upper)
　.filter(|&n_squared| is_odd(n_squared))
　.fold(0, |acc, n_squared| acc + n_squared);

**デフォルトの名無しさん** · 2021/11/07(日) 17:27:45.44

foldじゃなくてsumのほうが良いのでは

**デフォルトの名無しさん** · 2021/11/07(日) 17:29:32.83

let acc1: u32 = (0..).map(|n| n * n)
　.take_while(|&n_squared| n_squared < upper)
　.filter(is_odd)
　.sum()

**９９１** · 2021/11/07(日) 17:45:31.24

>>5
不意のミスでも結構コンパイルで引っかかってくれるようで安心しました。Rustさんよく考えられてますね。知りたかったことが書いてありました。ご丁寧にありがとうございます

**デフォルトの名無しさん** · 2021/11/07(日) 18:44:40.25

shadowing嫌いな人はdeny(clippy::shadow_same)などすればよい

**デフォルトの名無しさん** · 2021/11/07(日) 18:52:44.84

>>16
High orders functionはソースが配列かイテレーターか、いずれかで注意が必要です。配列の場合は以下の
英文のようになります。つまりそのサイズのメモリー領域が必要になるということです。またイテレータの
時でもある程度メモリーは当然使用しますが、それよりも遅延評価されるので注意が必要です。
Note on performance and stack usage
Unfortunately, usages of this method are currently not always optimized as well as they could be.
This mainly concerns large arrays, as mapping over small arrays seem to be optimized just fine.
Also note that in debug mode (i.e. without any optimizations), this method can use a lot of stack space
(a few times the size of the array or more).
Therefore, in performance-critical code, try to avoid using this method on large arrays or check
the emitted code. Also try to avoid chained maps (e.g. arr.map(...).map(...)).
個人的には深いチェーン呼び出しはあまり好きではありません。なぜなら状態をデバックしにくいからです。
パフォーマンス的な罠がありデバックしにくい事を抜けば、map,take_while,filterなどは何を行うかforに
比べ意図が明確になりますが、それは自己満足の幅が大きいとも言えます

**デフォルトの名無しさん** · 2021/11/07(日) 19:20:41.26

>>18のコードは大きな配列とかメモリ大量消費とかしないだろ
小さなstructを以下の4つ消費するのみで誤差
RangeFrom, Map, TakeWhile, Filter

**デフォルトの名無しさん** · 2021/11/07(日) 19:35:16.03

>>22
18のコードは配列ではなくイテレーターなのでそうですが、map,take_while,filterのほうが
好みの人が多いとは思いますが、私が言いたいのは何でもかんでもHigh orders functionに
して書くのはよく知らないと、リスクがあるということとブレークポイントなどを仕掛けて
経過は見れないということです。日本語が読めない人はもう少し考えましょう

**デフォルトの名無しさん** · 2021/11/07(日) 19:40:56.86

メソッドチェーンなら、メソッドごとに単体テストができるし、テストを用意しとけばすぐにバグがわかるような気がするが。