Rust part15

**デフォルトの名無しさん** · 2022/05/12(木) 18:28:20.99

公式
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を学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※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 part14
https://mevius.5ch.net/test/read.cgi/tech/1644596656/

**デフォルトの名無しさん** · 2022/05/12(木) 18:30:00.00

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/

**デフォルトの名無しさん** · 2022/05/12(木) 18:30:13.50

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/

**デフォルトの名無しさん** · 2022/05/12(木) 18:33:42.89

c++スレやHaskelスレでああでもないこうでもないと実用性無視してごちゃごちゃ言ってたのがRustスレに移って来て
ああでもないこうでもないと不毛な話を繰り返してるだけなんだろうな…

**デフォルトの名無しさん** · 2022/05/12(木) 21:06:22.42

let mut >>1乙

**デフォルトの名無しさん** · 2022/05/12(木) 23:07:25.38

ごちゃごちゃ戻り値の型さえ理解してないで書いてる

**デフォルトの名無しさん** · 2022/05/13(金) 01:13:09.90

またワッチョイなしですか

**デフォルトの名無しさん** · 2022/05/13(金) 04:12:30.14

>>6
ちゃんと理解しましょう

**デフォルトの名無しさん** · 2022/05/13(金) 06:02:56.68

乙
もっとRustが普及しますように☆彡

**デフォルトの名無しさん** · 2022/05/13(金) 18:17:33.08

>>7
ﾜｯﾁｮｲなんて飾りです

**デフォルトの名無しさん** · 2022/05/13(金) 21:57:27.44

>>7
ワッチョイスレはすでにあるだろ

**デフォルトの名無しさん** · 2022/05/13(金) 22:24:15.76

>>8
正直言うと、俺たちは若い奴らが何やらワイワイさわいでCOBOLおじさんJAVAおじさん、C#おじさん扱いされないよう
カッコよさげだから、なんとなく雰囲気でRustを書いてるんだ。
でも、うまく言えないけど理解する必要性を全く感じない、下請けにおまえRustも分らんの？とマウントするのが夢なんだ
とやかく言われる筋合いは無い

**デフォルトの名無しさん** · 2022/05/13(金) 23:48:07.30

再帰的なmacroはaliasしても展開時に
元の名前のマクロを使おうとしてエラーになるんだがこれって避けられない？

use foo_crate::foo as bar;
bar!(…)

cannot find macro `foo` in this scope
this error originates in the macro `bar`

**デフォルトの名無しさん** · 2022/05/14(土) 00:13:13.84

>>13
foo! の定義中の foo! 呼び出しを $crate::foo!() みたいにすればいけるんじゃないかな

**デフォルトの名無しさん** · 2022/05/14(土) 03:12:50.47

>>14
それだ、ありがとう

**デフォルトの名無しさん** · 2022/05/14(土) 23:50:01.31

前スレで出ていたこの上限チェックRangeFromだけど

fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: Clone + TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
itertools::unfold((start, true), move |(n, is_first)| {
if *is_first {
*is_first = false;
Some(n.clone())
} else {
n.checked_add(&one)
.map(|new| { *n = new.clone(); new })
}
})
}

フラグ持たずにOptionで持ったほうがわかりやすくない？

fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: Clone + TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
itertools::unfold(Some(start), move |n| {
let ret = n.clone();
if let &mut Some(ref m) = n {
*n = m.checked_add(&one);
}
ret
})
}

**デフォルトの名無しさん** · 2022/05/15(日) 00:14:36.59

複オジに毒されてるな

successors(Some(start), move |n| n.checked_add(&one))

**デフォルトの名無しさん** · 2022/05/15(日) 02:25:52.10

>>16
そのclone()は不要
トレイト境界からCloneを外せる

fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
itertools::unfold(Some(start), move |n| {
if let &mut Some(ref m) = n {
let mut next = m.checked_add(&one);
std::mem::swap(n, &mut next);
next
} else {
None
}
})
}

**デフォルトの名無しさん** · 2022/05/15(日) 03:11:19.26

unfoldでなんでもできるからunfoldしか使わなくなってしまった人
いろいろな人

**デフォルトの名無しさん** · 2022/05/15(日) 07:53:49.50

>>18
take()?でもっと簡潔に書ける

fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
itertools::unfold(Some(start), move |n| {
let cur = n.take()?;
*n = cur.checked_add(&one);
Some(cur)
})
}

**デフォルトの名無しさん** · 2022/05/15(日) 08:07:10.15

>>19
unfoldは要点に絞って見やすい短縮記法として使われている
そのままunfoldを使わずに普通に構造体にimpl Iteratorする形へ置き換え可能なところがメリット

例えば>>20はそのまま機械的に以下へ展開できて同じく動作する
struct Countup<T> {
one: T,
n: Option<T>,
}

fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
Countup {
one: T::try_from(1).ok().unwrap(),
n: Some(start),
}
}

impl<T> Iterator for Countup<T>
where T: num::CheckedAdd,
{
type Item = T;
fn next(&mut self) -> Option<T> {
let cur = self.n.take()?;
self.n = cur.checked_add(&self.one);
Some(cur)
}
}

これだと長く冗長なので敢えてunfold利用版を記述することで要点のみに絞ることができる

**デフォルトの名無しさん** · 2022/05/15(日) 10:14:06.42

>>19
全部同じやつだぞ
一人二役で会話してる

**デフォルトの名無しさん** · 2022/05/15(日) 10:54:06.34

unfoldより関係が分かりにくくなるけど
キャプチャした変数を使うfrom_fnという手もある

fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
let mut n = Some(start);
let one = T::try_from(1).ok().unwrap();
std::iter::from_fn(move || {
let cur = n.take()?;
n = cur.checked_add(&one);
Some(cur)
})
}

**デフォルトの名無しさん** · 2022/05/15(日) 10:54:14.40

大人が集まってくつろいでるところに
子供がガラッと入ってきて九九の暗唱しはじめたら
頑張ってるのがほほえましくて応援しちゃうでしょ
でも
大人がガラッと入ってきて九九の暗唱しはじめたら
ギョッとするし不安になってくるやろ
なぜそんなもんをお披露目しちゃうのか
なぜ得意げになって頑張ってるのかわからない
もういいよ！と単に言えばいいのか
続きはカーチャンに見えもらってね！と言えば良いのか
言って分かってもらえる気配もないので怖い

**デフォルトの名無しさん** · 2022/05/15(日) 11:10:33.42

今回はこれでもいい

fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
std::iter::successors(Some(start), move |n| n.checked_add(&one))
}

**デフォルトの名無しさん** · 2022/05/15(日) 11:16:38.61

はちみつおじさん悔しそうwww

**デフォルトの名無しさん** · 2022/05/15(日) 12:24:43.22

九九と違って子供用のおもちゃプログラムでしか使えないコードなんだよなぁ

**デフォルトの名無しさん** · 2022/05/15(日) 12:39:00.79

代案出さずに文句だけつける万年野党みたいなやつがいるな

**デフォルトの名無しさん** · 2022/05/15(日) 13:13:50.62

>>25
それまんま>>17やんけ

**デフォルトの名無しさん** · 2022/05/15(日) 14:22:42.46

九九のように簡単だという皆さま方に質問です
countup()が7通り(?)も色んな書き方が出てきて驚いたのですが
フィボナッチ数列だとどんな華麗なコードになりますか？

fn fibonacci<T>() -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
// ここを記述
}

出力仕様は一番ベーシックな0スタートとします
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

**デフォルトの名無しさん** · 2022/05/15(日) 15:13:51.95

>>30
「Rustのお題スレ」でも立ててそっちでやってくれ

**デフォルトの名無しさん** · 2022/05/15(日) 15:27:49.70

>>31
難しくて解けないという表明ですか？
どういう点が難しかったのか教えてください

**デフォルトの名無しさん** · 2022/05/15(日) 15:40:51.12

教えてもらったsuccessorsを披露したくてしょうがない幼児メンタルwww

>>24の言う通りだな

**デフォルトの名無しさん** · 2022/05/15(日) 15:49:35.48

>>33
successorsは適用範囲が非常に狭いので>>30の例には使えないはず

**デフォルトの名無しさん** · 2022/05/15(日) 16:09:35.61

>>33
ぜひそれを披露してやり方を教えてください

**デフォルトの名無しさん** · 2022/05/15(日) 16:27:05.61

フィボナッチ数列イテレータ前スレでだれかが書いてたでしょ
それじゃいかんの

**デフォルトの名無しさん** · 2022/05/16(月) 07:04:42.44

>>36
CopyやCloneを使っているから別問題だろう。
一般的にRustのプログラミングでは、
Copy(暗黙的な自動コピー)やClone(clone()による明示的な手動コピー)を使うと楽になるが、コストは高くなる。
そのため不要なclone()を見極めてそれを回避するプログラミングが出来るかどうか、というRustにおける根源的な話だろう。

**デフォルトの名無しさん** · 2022/05/16(月) 07:28:24.60

Copyのコストが高い？

**デフォルトの名無しさん** · 2022/05/16(月) 08:00:50.97

>>38
もちろんCopyは最もコストが高い。
個々のコスト自体は通常clone()と同じだが、常に自動的にclone()が起きるため最もコストが高くなる。

**デフォルトの名無しさん** · 2022/05/16(月) 08:58:48.98

複製おじさんはいつも自分勝手な妄想を「一般的には～」とか「皆は～」と言って自分を正当化しようとするよね

**デフォルトの名無しさん** · 2022/05/16(月) 10:03:10.22

>>40
間違いは誰にでもあるからまだいいんだが
指摘されても反省するどころかさらなる妄想を撒き散らすのがほんと迷惑

**デフォルトの名無しさん** · 2022/05/16(月) 11:11:33.48

おじさん使いの人の自演がいつもよくわからん
唐突に妄想(?)を攻撃し出すが幻覚か何か見えてるのか

**デフォルトの名無しさん** · 2022/05/16(月) 16:19:03.24

>>39
Cloneのコストが高い型にCopyを実装するな

**デフォルトの名無しさん** · 2022/05/16(月) 16:30:48.20

Copyはコストが一番高いから出来る限り避けるべきだな
特にヒープを使うならCloneまでにしておくべき
可能ならばCloneも避けるべきだが

**デフォルトの名無しさん** · 2022/05/16(月) 18:08:42.72

Copyは所有権を複製するから最も高コスト(ｷﾘｯ！！

**デフォルトの名無しさん** · 2022/05/16(月) 18:10:04.46

もはやどのレスもギャグにしか見えん
俺のしってるCopyとは確実に違う

**デフォルトの名無しさん** · 2022/05/16(月) 18:38:28.59

今までで一番意味不明なこと言ってるな
Copyのコストが高いならmoveのコストはどうなるのよ

**デフォルトの名無しさん** · 2022/05/16(月) 18:44:18.84

>>45
所有権に複製という概念はない
Copyをimplすると使われる時に値が自動的に複製される
そのためCopyは最も高コスト

>>46
君のレスがギャグにしか見えん

**デフォルトの名無しさん** · 2022/05/16(月) 18:47:50.19

Rust のムーブはビットパターンのコピーだもんな。
低レイヤの視点で見たらコピーと何の差も無い。

なるべく参照を使う場合にしても間接参照の実行コストとコピーの実行コストを天秤にかけてどちらが有利かは場合による。

**デフォルトの名無しさん** · 2022/05/16(月) 18:55:12.38

>>47
それは理解不足すぎるぜ
大文字のCopyはCopyトレイトを意味しCopyトレイトを実装するか否かの話だろ
moveは別方向の話であり比較対象にすらならない
比較するならば「Copy実装(必然的にClone)も実装」「Cloneのみ実装」「どちらも実装なし」の3つだな

**デフォルトの名無しさん** · 2022/05/16(月) 19:00:08.16

>>48
ギャグだと分からない人がいるとは想定していませんでした。
誤解を招いたのであれば申し訳ございません。

**デフォルトの名無しさん** · 2022/05/16(月) 19:06:18.85

>>49
デタラメすぎ
ムーブでビットパターンのコピーは発生しない
ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
Copyのコピーはディープであって高コスト

**デフォルトの名無しさん** · 2022/05/16(月) 19:08:38.74

そもそもフィボナッチ数列イテレータなんて誰も求めてないので
前スレのだれかさんの実装に問題があると思うなら自分で勝手に改善してなさい
そしてその結果はここに貼らなくていいぞ

**デフォルトの名無しさん** · 2022/05/16(月) 19:11:06.58

「ヒープ使うならCloneまでにしとけ」
このセリフが一番刺さった

**デフォルトの名無しさん** · 2022/05/16(月) 19:11:50.62

>>52
おじさんマジかよwww

**デフォルトの名無しさん** · 2022/05/16(月) 19:22:59.76

>>54
Dropを実装する型はCopyを実装できないよ
BoxもRcもStringもVecもそもそもCopyを実装できないので、するかしないか考えること自体が無意味

どういう型にCopyを実装できるか、できないか、すべきかはdocsに書いてあるので
なんのかんの言う前にまずはこれを読もうね
https://doc.rust-lang.org/std/marker/trait.Copy.html

**デフォルトの名無しさん** · 2022/05/16(月) 19:37:56.79

>>53
これだけCopyやCloneを理解していない連中が多い状況だと
>>30の質問に答えられるかどうかは最低限クリアすべきテストとして有用ではないか？
フィボナッチ自体はもちろんどうでもよい話だがCopyやCloneを避けるRustの基本ができるかどうかわかる点で

**デフォルトの名無しさん** · 2022/05/16(月) 19:45:37.77

>>52
じゃあムーブでなにが起こるとおもってんの？

**デフォルトの名無しさん** · 2022/05/16(月) 19:54:25.89

>>53
> フィボナッチ数列イテレータなんて誰も求めてない

それはそうなんだけど
唯一本人にとっては伝家の宝刀だから
少なくともこのスレいっぱいまでは引っ張って
何度も何度も参照するはず

**デフォルトの名無しさん** · 2022/05/16(月) 20:38:11.38

フィボナッチがどうでもいいならこの話は終わりです

**デフォルトの名無しさん** · 2022/05/16(月) 20:45:13.08

関数の深いところから順に構造体をムーブで返していって
各関数で渡ってきた構造体のアドレスを表示させてみた

#[derive(Debug)]
struct S([i32; 100]);

fn main() {
let mut s1 = sub1(100);
s1.0[1] = 111;
println!("s1: {:p}", &s1);
println!("{s1:?}");
}

fn sub1(p: i32) -> S {
let q = p + 3;
let mut s2 = sub2(q);
s2.0[2] = p - 300;
println!("s2: {:p}", &s2);
s2
}

fn sub2(s: i32) -> S {
let t = s * 2;
let mut s3 = S([123; 100]);
s3.0[3] = t;
println!("s3: {:p}", &s3);
s3
}

s1もs2もs3もアドレスが一致
ムーブではアドレスそのままであり
ビットパターンのコピーが為されないという結論

**デフォルトの名無しさん** · 2022/05/16(月) 20:58:36.88

>>50
"Copyのコストが高い" は Copy を実装する行為そのもののコストが高いと解釈すべきということ？
そんなばかな

>>52
ドキュメント読みましょうねー

https://doc.rust-lang.org/stable/std/marker/trait.Copy.html
> It’s important to note that in these two examples, the only difference is whether you are allowed to access x after the assignment.
> Under the hood, both a copy and a move can result in bits being copied in memory, although this is sometimes optimized away.
...
> The behavior of Copy is not overloadable; it is always a simple bit-wise copy.
...
> The implementation of Clone can provide any type-specific behavior necessary to duplicate values safely.
> For example, the implementation of Clone for String needs to copy the pointed-to string buffer in the heap.

**デフォルトの名無しさん** · 2022/05/16(月) 21:06:43.52

>>61
アドレスが同じか否かでコピーの有無を判断する意味はよくわからんが
その理屈だとこのコードだと違うアドレスが表示されるからビットパターンのコピーがされてるって結論になるのか？

#[derive(Debug)]
struct S([i32; 100]);

fn main() {
let mut s1 = S([0; 100]);
println!("s1: {:p}", &s1);
let s2 = s1;
println!("s2: {:p}", &s2);
}

**デフォルトの名無しさん** · 2022/05/16(月) 21:07:20.55

>>61
struct S {}
fn main() {
let s1 = S{};
println!("s1: {:p}", &s1);
let s2 = s1;
println!("s2: {:p}", &s2);
}

**デフォルトの名無しさん** · 2022/05/16(月) 21:08:00.98

ごめん被った。やっぱそう思うよね。

**デフォルトの名無しさん** · 2022/05/16(月) 21:16:19.81

>>56
ちょっとw
なんで刺さったのか少しは考えてよww
ギャグゴロシめ

**デフォルトの名無しさん** · 2022/05/16(月) 21:19:28.47

>>61
>>63
その二つの相異なる結果を見るとビットパターンのコピーはムーブ以外の要因で起きている？？

**デフォルトの名無しさん** · 2022/05/16(月) 21:30:56.46

>>57
一番分かってないお前が言うなよw

**デフォルトの名無しさん** · 2022/05/16(月) 21:38:19.38

>>61
高コストなCopyも実装してから確認してみてねww

**デフォルトの名無しさん** · 2022/05/16(月) 21:38:29.32

>>66
ごめんよ
刺さったって「ためになった」みたいな意味で言ってるのかと思ったよ
てっきりオジの自演かと

**デフォルトの名無しさん** · 2022/05/16(月) 21:39:12.01

>>67
デバッグビルドだけじゃなくリリースビルドでも確認してねw

**デフォルトの名無しさん** · 2022/05/16(月) 21:42:44.19

>>71
リリースモードでもどちらも同じ結果

**デフォルトの名無しさん** · 2022/05/16(月) 21:49:25.30

>>72
ごめんよー
>>64と間違えた

**デフォルトの名無しさん** · 2022/05/16(月) 23:46:37.66

このスレはいつもおかしい人間たちが集まってるな
Rustの何が人を狂わせるんだ？

**デフォルトの名無しさん** · 2022/05/17(火) 00:09:43.95

おじさんイジリ飽きたので結論いっておく

Copyもmoveもスタックの中身をコピーしてるのは同じ
最適化によって不要なコピーが除去されるかどうかはLLVM次第
でかい配列やでかい構造体などの極一部を除けばCopyは参照の受け渡しよりも低コスト
ついでに言うと&TもCopy

**デフォルトの名無しさん** · 2022/05/17(火) 00:26:01.61

>>75
頭悪すぎ
Copyが低コストなのではなく
低コストなものだけにCopyが実装されている
なぜならCopyは高コストであるため

**デフォルトの名無しさん** · 2022/05/17(火) 02:09:56.03

>>76
ここでいうCopyのコストって具体的にどういう操作のコストのこと言ってる？
構造体データのbitwise-copyのこと？それとも別の何か？
Cloneやmoveの場合にそのコストは発生しないと主張しているの？

**デフォルトの名無しさん** · 2022/05/17(火) 02:13:55.30

>>62
ほーCopyってCloneの実装によらずmemcpy相当の結果になるのか
自動的に.clone()が差し挟まれる感じかと思ってた

**デフォルトの名無しさん** · 2022/05/17(火) 07:41:41.18

>>78
俺も同じくCopyは自動的にclone()されると思ってた
そう思ってた理由はClone実装せずにCopy実装するとエラーとなるため
そこで実験

#[derive(Debug,Copy)]
struct S { not_cloned: usize, cloned: usize }
impl Clone for S {
fn clone(&self) -> Self {
S { not_cloned: self.not_cloned / 3, cloned: self.cloned }
}
}

fn main() {
let s0 = S { not_cloned: 123, cloned: 456 };
let s1 = s0.clone();
let s2 = s0; // copy
println!("Cloned: {s1:?}");
println!("Copied: {s2:?}");
}

結果
Cloned: S { not_cloned: 41, cloned: 456 }
Copied: S { not_cloned: 123, cloned: 456 }
別物になった…

**デフォルトの名無しさん** · 2022/05/17(火) 10:53:02.16

>>52
>>>49
>デタラメすぎ
>ムーブでビットパターンのコピーは発生しない
>ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
>さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
>Copyのコピーはディープであって高コスト

このレス最強だな
一つ一つの文すべてが間違ってる
「デタラメすぎ」てw

**デフォルトの名無しさん** · 2022/05/17(火) 14:50:42.61

ガイジムーブ来てんね

**デフォルトの名無しさん** · 2022/05/17(火) 21:03:27.69

Copyはshallow copyだわな

**デフォルトの名無しさん** · 2022/05/17(火) 22:07:44.57

色々と正確な情報が出揃ったところで質問

まず前提として話を明白かつ簡単にするため、
ここでは!DropつまりCopy実装可能な型のみ対象、
そしてもしClone実装するならば*selfつまりCopy実装と同一、
CloneやCopyを実装するかどうかは任意、
小文字のcloneとcopyはそれぞれCloneやCopyを実装した時にそれらが使われることを意味するとする

このとき、次のどちらの主張が正しい？
Ａ「copy/cloneはコストが生じるので、回避できるならば回避したほうが有利」
Ｂ「copy/cloneのコストはmoveと同じなので回避する必要はない」

**デフォルトの名無しさん** · 2022/05/17(火) 22:30:37.28

場合による。
たとえコピーであっても結局は内容が同じものであると看破すれば
実際にはコピーしないようなコードを生成するといったことは有りうる。
Rust は原理的にエイリアス解析がやりやすい言語だと思うし。
実行コスト的にどうかなんて考えずに所有権管理の側面からの妥当性で決めたほうがよい。
その上でどうしても実行コストを切り詰めないといけないようになったならその時に考えればいい。

**デフォルトの名無しさん** · 2022/05/17(火) 22:33:27.98

>>83
前提もまちがってるが
比較する対象がそもそも意味がない

もうちょっと勉強してから出直して

**デフォルトの名無しさん** · 2022/05/17(火) 23:40:20.70

>>83
>Ａ「copy/cloneはコストが生じるので、回避できるならば回避したほうが有利」
何と比べてコストが生じると言ってるの？
回避した場合は何で代用するつもりなの？

**デフォルトの名無しさん** · 2022/05/17(火) 23:43:19.03

考えてみたけどmove/copyが問題になるレベルの大きさの型をスタックに置いて扱ったことが無いな…

使うとすれば固定長配列のバッファ？
でもそんなものmove/copyするわけないし
やっぱり考える意味の無い二択だと思う

**デフォルトの名無しさん** · 2022/05/17(火) 23:47:41.13

>>86
回避する前と回避した後の比較だろう
回避したコードが書けたならばcopyの代用の必要はない

**デフォルトの名無しさん** · 2022/05/17(火) 23:49:36.53

>>83
一般的にはAが正しい
ただし>>84が言うように無駄なコピーが消える場合もある
Ａ「copy/cloneはコストが生じるので、回避できるならば回避したほうが有利になることがある」ならば正確
Bについては前半はある意味正しいとしても後半が間違い

>>85
批判や主張はその理由を伴わないと議論とならず意味がない

**デフォルトの名無しさん** · 2022/05/17(火) 23:54:01.76

>>89
> 批判や主張はその理由を伴わないと議論とならず意味がない

基本的にはそうだが、こっちが説明しても理解できるレベルに達してない場合にはどうせ議論にならんのでな。

**デフォルトの名無しさん** · 2022/05/17(火) 23:55:13.39

あっこの流れC++相談室で見たやつだ

**デフォルトの名無しさん** · 2022/05/18(水) 00:07:06.58

要は参照使えるなら使っとけって？
今更すぎませんか

**デフォルトの名無しさん** · 2022/05/18(水) 00:30:37.66

オナコードペタペタされてたほうがマシだったなこりゃ

**デフォルトの名無しさん** · 2022/05/18(水) 00:45:17.78

>>92
それもあるが、例えば多数のコピーが行われているコードに対して、回避できる分を見直し、少数のコピーで済むように改善できる場合もある
Copy実装せずに明示clone()した方が見つけやすいかもしれない

**デフォルトの名無しさん** · 2022/05/18(水) 01:26:17.77

>>88
さすがに意味が分からないよ
値の受け渡しにcopyを使わないなら何が他の方法を使う必要があるでしょ

**デフォルトの名無しさん** · 2022/05/18(水) 01:42:43.25

一人だけ間違った思い込みをしてるのに
説明されても「俺は間違ってない、間違ってるのはお前ら」が続くだけだからな

**デフォルトの名無しさん** · 2022/05/18(水) 01:46:16.75

>>95
頭が硬すぎないか？
回避できる分を回避するだけだろ
回避できない分まで回避する、と思い込んてるのはYouのみ

**デフォルトの名無しさん** · 2022/05/18(水) 01:51:55.82

>>89
「○○はコストが生じるので、回避できるならば回避したほうが有利になることがある」

言葉の定義を明確にしないジェネリック文は
恣意的に常に真にも常に偽にもできる

**デフォルトの名無しさん** · 2022/05/18(水) 02:06:14.30

>>90
無駄にプライド高いな
嫌われるぜ

**デフォルトの名無しさん** · 2022/05/18(水) 07:08:20.63

大きいフィールドを持つ型には、Copyは実装しないだろうし普通はCopy/Moveのコスト差を気にすることなくない？
どちらにすべきかボーダーが難しいことはありそうだけど

**デフォルトの名無しさん** · 2022/05/18(水) 07:14:11.27

>>94
データフローを見直して単純に消せるclone/copyは消せってことか？
それこそ今更すぎるわ
単純に消せないところまで消した後、さらにパフォーマンス改善するにはどうするかってことで、参照の話か？って聞いたんだけど

どこの誰とも知れないやつのフィボナッチのコードに対する指摘をされても知らねーよ
問題があって対策が分かってるなら自分で直すがいい

**デフォルトの名無しさん** · 2022/05/18(水) 07:41:25.51

>>97
実行回数の話だったのかよww
まさかねw

**デフォルトの名無しさん** · 2022/05/18(水) 07:56:39.00

>>101
フィボナッチの件はBigIntなど非Copyも対象で今回の話は全く無関係だろ
そこを区別できていないのは相当ヤバいぞ

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

流れからすると本当はジェネリックのフィボナッチにCopyを付けないほうが有利と主張したかったんじゃね？

でも後から回避できないことに気づいて苦しい言い訳を重ねてるだけと見た

**デフォルトの名無しさん** · 2022/05/18(水) 08:21:27.45

>>85
根拠も示さず批判だけする一番アカン人間やな

**デフォルトの名無しさん** · 2022/05/18(水) 08:33:04.08

>>104
フィボナッチはCopyを回避できないものなの？

**デフォルトの名無しさん** · 2022/05/18(水) 08:45:43.18

分からないなら分からないから教えてって言えばいいのに意地を張るからこうなる
構えば構うほど意味不明な発言が出てくる

真面目に議論したいならせめてIDコロコロ変えるのやめな

**デフォルトの名無しさん** · 2022/05/18(水) 09:10:15.39

フィボナッチってこれだろ
f(0) = 0
f(1) = 1
f(n) = f(n - 1) + f(n - 2)
関数呼び出しに足し算に大量のコピーは避けられない

**デフォルトの名無しさん** · 2022/05/18(水) 09:28:25.87

>>87
async関数やasyncブロックで生成されるFutureは結構大きくなることがあって、boxingした方が性能出るケースもある

**デフォルトの名無しさん** · 2022/05/18(水) 10:05:07.09

>>106
型制約からCopyを外すこことcopyを回避することは全く意味が違う
>>83の質問は明らかに後者

プリミティブも対象になるフィボナッチでcopyを回避するのは無理

**デフォルトの名無しさん** · 2022/05/18(水) 10:20:40.09

>>110
型制約からCopyを外せばプリミティブと言えどもcopyされなくなる
具体的には個々のプリミティブ型へモノモーフィゼーゼーションされる前の段階でCopy実装していない型に対してのcopy発生エラーが生じる
フィボナッチでcopyを回避するのは可能

**デフォルトの名無しさん** · 2022/05/18(水) 10:38:43.35

複オジの主張まとめ(1)
37, 39, 44
=====
CopyやCloneを使っているから別問題だろう。
一般的にRustのプログラミングでは、
Copy(暗黙的な自動コピー)やClone(clone()による明示的な手動コピー)を使うと楽になるが、コストは高くなる。
そのため不要なclone()を見極めてそれを回避するプログラミングが出来るかどうか、というRustにおける根源的な話だろう。

もちろんCopyは最もコストが高い。
個々のコスト自体は通常clone()と同じだが、常に自動的にclone()が起きるため最もコストが高くなる。

Copyはコストが一番高いから出来る限り避けるべきだな
特にヒープを使うならCloneまでにしておくべき
可能ならばCloneも避けるべきだが

**デフォルトの名無しさん** · 2022/05/18(水) 10:39:05.95

複オジの主張まとめ(2)
50, 52, 57
=====
それは理解不足すぎるぜ
大文字のCopyはCopyトレイトを意味しCopyトレイトを実装するか否かの話だろ
moveは別方向の話であり比較対象にすらならない
比較するならば「Copy実装(必然的にClone)も実装」「Cloneのみ実装」「どちらも実装なし」の3つだな

デタラメすぎ
ムーブでビットパターンのコピーは発生しない
ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
Copyのコピーはディープであって高コスト

これだけCopyやCloneを理解していない連中が多い状況だと
>>30の質問に答えられるかどうかは最低限クリアすべきテストとして有用ではないか？
フィボナッチ自体はもちろんどうでもよい話だがCopyやCloneを避けるRustの基本ができるかどうかわかる点で

**デフォルトの名無しさん** · 2022/05/18(水) 10:41:41.09

複オジの一連の主張を読んでから>>83の複オジ質問を読むべし

**デフォルトの名無しさん** · 2022/05/18(水) 10:44:21.46

複おじに反応するやつも複おじ

**デフォルトの名無しさん** · 2022/05/18(水) 10:52:26.71

主張が毎回変わる
口調も毎回変わる
表記も毎回変わる
間違いなく多重人格者

**デフォルトの名無しさん** · 2022/05/18(水) 10:55:48.57

>>98
この文脈では○○にはなんでも当てはまるから意味がないよね

以下なら議論になる？
Ａ「copy/cloneはmoveよりコストが生じるので、copyが必要な部分とそうでない部分で構造体を分離してでも出来るだけmoveを使用する」
Ｂ「copy/cloneのコストはmoveよりコストが生じるとは限らないので、一部でもcopyが必要な部分がある構造体は丸ごとcopyして構わない」

**デフォルトの名無しさん** · 2022/05/18(水) 11:00:11.80

>>116
そこまでいったらネット上では別人で良いだろ

**デフォルトの名無しさん** · 2022/05/18(水) 11:05:55.27

>>108
やってみた

fn main() {
for n in 0..100 {
let f = f(n);
println!("f({n}) = {f}");
}
}

fn f(n: i32) -> i32 {
match n {
0 => 0,
1 => 1,
n => f(n - 1) + f(n - 2),
}
}

このあたりから非常に重くなった
f(43) = 433494437
f(44) = 701408733
f(45) = 1134903170
f(46) = 1836311903
f(47) = -1323752223
f(48) = 512559680

**デフォルトの名無しさん** · 2022/05/18(水) 11:24:29.81

メモ化されてないんやから遅くなるのは当然
>>108は定義を示しただけちゃう？

**デフォルトの名無しさん** · 2022/05/18(水) 11:25:30.07

つかオーバーフローしとるな

**デフォルトの名無しさん** · 2022/05/18(水) 11:29:30.10

>>119
そのコードだとcopyは何回くらい発生してるのだろう
0回？1回？2回？3回？たくさん？

**デフォルトの名無しさん** · 2022/05/18(水) 12:13:31.53

ぼくのかんがえたさいきょうのcountup<T>()をみんなバカにしたので
ぼくのかんがえたさいきょうのfibonacchi<T>()でやっつけようとしたら
わざをだすまえにボコボコにやられてしまいました
く、くやしいです！

**デフォルトの名無しさん** · 2022/05/18(水) 13:41:52.15

clone()が一個でコンパイル通ったからそのコードでのコピーは一回ではないか

use std::ops::{Add, Sub};
fn f<T>(n: T) -> T where T: Clone + PartialEq + TryFrom<usize> + Add<Output=T> + Sub<Output=T> {
let [zero, one, two] = [0, 1, 2].map(|n| T::try_from(n).ok().unwrap());
match n {
n if n == zero => zero,
n if n == one => one,
n => f(n.clone() - one) + f(n - two),
}
}

**デフォルトの名無しさん** · 2022/05/18(水) 13:50:00.30

>>119
計算量はO(n), メモリ使用量は定数オーダーにできるのになんで定義どおり実装したの？

**デフォルトの名無しさん** · 2022/05/18(水) 14:41:04.77

>>123
ぼくのかんがえたさいきょうのfizzbuzz<T>()もわすれないで

**デフォルトの名無しさん** · 2022/05/18(水) 15:04:45.49

>>125
そんな魔法はありません

**デフォルトの名無しさん** · 2022/05/18(水) 16:48:40.40

>>127
え？

**デフォルトの名無しさん** · 2022/05/18(水) 17:53:48.13

Rust以前の問題じゃん
スレ違い

**デフォルトの名無しさん** · 2022/05/18(水) 23:22:25.69

>>124
そのclone()は子のf(n-1)とf(n-2)やそれらの子孫でも呼ばれるので1回ではなくO(n)より大きい
それをO(n)すなわちn回＋定数回以下に抑えられるのかどうか
あるいはO(0)回すなわち定数回以下に抑えられるのかどうか

**デフォルトの名無しさん** · 2022/05/18(水) 23:41:48.24

フィボナッチはu128を使ってもf(187)でオーバフローするからBigInt必須
clone()はできる限り少なくしないと厳しい

**デフォルトの名無しさん** · 2022/05/19(木) 00:10:47.96

どうでもいいから複おじはTRPL読み直してきてね

**デフォルトの名無しさん** · 2022/05/19(木) 00:16:28.52

>>120
メモ化したら速くなったけど
memoをこちらで用意して毎回渡していくのを避けられないのかな？

fn main() {
let mut memo: Vec<usize> = Vec::new();
for n in 0..100 {
let f = f(n, &mut memo);
println!("f({n}) = {f}");
}
}

fn f(n: usize, memo: &mut Vec<usize>) -> usize {
if let Some(result) = memo.get(n) {
*result
} else {
let result = match n {
0 => 0,
1 => 1,
n => f(n - 1, memo) + f(n - 2, memo),
};
memo.push(result);
result
}
}

**デフォルトの名無しさん** · 2022/05/19(木) 00:24:17.53

メモ化する必要ある？
直前の2つだけ記録しておけば次の一項が計算できるんだから再帰にする必要ないよね

**デフォルトの名無しさん** · 2022/05/19(木) 00:33:12.40

>>134
具体的にどうすればよいてすか？

**デフォルトの名無しさん** · 2022/05/19(木) 00:46:08.98

>>135
"rust fibonacci"でググるとよいです

**デフォルトの名無しさん** · 2022/05/19(木) 01:21:23.38

>>134
直前の2つだけ記録して再帰にしない方法ならば
おそらくこうする案だと思うが
>>133がO(n)で済んでいるのに対して
これは二重のforによりO(n^2)になっていてこれは悪手

fn main() {
for n in 0..100 {
let f = f(n);
println!("f({n}) = {f}");
}
}

fn f(n: usize) -> usize {
match n {
0 => 0,
1 => 1,
n => {
let mut prepre = 0;
let mut pre = 1;
for i in 2..n {
let tmp = pre;
pre += prepre;
prepre = tmp;
}
pre + prepre
},
}
}

**デフォルトの名無しさん** · 2022/05/19(木) 01:31:14.77

>>135
fn main(){
for n in 0..10{
println!("f({}) = {}", n, f(n));
}
}
fn f(n:usize) -> usize{
let mut a = 0;
let mut b = 1;
for i in 0..n{
let tmp = b;
b = a + b;
a = tmp;
}
return a;
}

わざわざRustっぽい書き方をする必要はない

**デフォルトの名無しさん** · 2022/05/19(木) 01:39:04.90

>>138
それもforが二重となっていて全体でO(n^2)だから同じく悪手

**デフォルトの名無しさん** · 2022/05/19(木) 02:09:27.74

>>131
なら尚のことジェネリックにする意味ないよね？

**デフォルトの名無しさん** · 2022/05/19(木) 03:45:23.95

>>137,139
悪手ってなにをもって悪手だよ
一般項の導出は高校生でもできるレベルで、そうすればO(log(n))で求められるし、つまらん計算量改善のためだけのアルゴリズム議論はもうやめろ
これ以上計算量の話をするなら別のスレでやってくれ

**デフォルトの名無しさん** · 2022/05/19(木) 04:01:44.79

>>141
mainに既にforループがある
だから個々をO(n)で求めると全体でO(n^2)となる
もし個々をO(log(n))で求めたとしても全体でO(n✕log(n))となる
一方で>>133は優れていて全体でO(n)だから圧倒的に良手

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

まあ(usize) -> usizeのインターフェースを持たせつつ逐次処理したければメモ化が楽だわな
Rustとは特に関係の無いアルゴリズム一般論の話だけど

**デフォルトの名無しさん** · 2022/05/19(木) 12:20:27.39

なんでmainのループまで計算量に入れてるの？
今やってるのはフィボナッチ数列の計算量の話でしょ
余計なところまで話し広げてどうするの？

**デフォルトの名無しさん** · 2022/05/19(木) 12:42:29.01

いい加減こんな語り尽くされた話終わってろ
何スレだよここ

**デフォルトの名無しさん** · 2022/05/19(木) 12:44:11.02

>>143
メモ化は良いが>>133のコードはインターフェースがあまりよくない
逆に>>138のコードはn個の列挙にO(n^2)も費やしている
以下のように書けばn個の列挙がO(n)に収まり、個別f(n)もO(n)で両立できる

fn main() {
println!("f(77) = {}", f(77));
for (n, f) in fibonacci_iter().enumerate() {
println!("f({n}) = {f}");
}
}

fn f(n: usize) -> usize {
fibonacci_iter().nth(n).unwrap()
}

fn fibonacci_iter() -> impl Iterator<Item=usize> {
let mut p = 0;
let mut q = 1;
std::iter::from_fn(move || {
let r = p;
p = q;
q += r;
Some(r)
})
}

**デフォルトの名無しさん** · 2022/05/19(木) 12:47:27.97

僕チンすごい！ってホルホルしたいんだろうけど

脳のワーキングメモリーが減ってこの程度の内容でしかコードが書けないんだろうな

**デフォルトの名無しさん** · 2022/05/19(木) 13:06:09.75

まず計算量にmainのループを勘定してる時点で…

**デフォルトの名無しさん** · 2022/05/19(木) 13:18:54.57

>>144
> 今やってるのはフィボナッチ数列の計算量の話でしょ

その通りでアンタが正しい

>>148
フィボナッチ『数列』の計算量だから
mainのループを勘定するのは当然
f(0)、f(1)、f(2)、…、f(n)がフィボナッチ『数列』

**デフォルトの名無しさん** · 2022/05/19(木) 18:50:45.11

イテレーターにするとメリット多いんだな
Rustと相性いい

**デフォルトの名無しさん** · 2022/05/19(木) 19:01:17.07

>>146はメモ捨ててるから計算済みのf(n)引っ張ってくるのに毎回O(n)かかるけどね
イテレータと相性良いように見えるとしたら0..nループと組み合わせることしかしてこなかったmainが見せる幻想

そろそろRustの話に戻ってもらっていいですか？

**デフォルトの名無しさん** · 2022/05/19(木) 19:56:30.02

>>151
マジで>>133のメモ化が好ましいと思っているのか？
イテレータはメモ化とも相性が良い
例えば>>146のfibonacci_iter()を含むイテレータ汎用メモ化は即席でこんな感じ

fn main() {
let mut memo = IterMemo::new(fibonacci_iter());
assert_eq!(memo.nth(10), Some(55));
assert_eq!(memo.nth(0), Some(0));
assert_eq!(memo.nth(30), Some(832040));
assert_eq!(memo.nth(5), Some(5));
assert_eq!(memo.nth(50), Some(12586269025));
}

struct IterMemo<I> {
iter: I,
memo: Vec<usize>,
}

impl<I: Iterator<Item=usize>> IterMemo<I> {
fn new(iter: I) -> Self {
IterMemo { iter, memo: Vec::new() }
}
fn nth(&mut self, n: usize) -> Option<usize> {
for _i in self.memo.len()..=n {
if let Some(x) = self.iter.next() {
self.memo.push(x);
}
}
self.memo.get(n).cloned()
}
}

**デフォルトの名無しさん** · 2022/05/19(木) 21:07:44.82

汚いな

**デフォルトの名無しさん** · 2022/05/19(木) 21:11:33.57

複オジは何が問題だと指摘されてるのか理解しないんだよなぁ
頭悪いのにとにかくマウントだけ取りたがって恥の上塗り上塗り上塗り
何回塗るねんっw

**デフォルトの名無しさん** · 2022/05/19(木) 21:20:54.65

ほらなｗ
ぼくのかんがえたさいきょうのひぼなっちいてれーた！
どや！？　どやどやどや！！？
これで1000まで行くよｗ

**デフォルトの名無しさん** · 2022/05/19(木) 21:27:22.70

どうしてもイテレータが欲しいなら>>133に建て増ししたほうがよっぽど整理されていいよ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=86c556a9709d959e8b9ecff08223b099

**デフォルトの名無しさん** · 2022/05/19(木) 21:29:51.14

>>152
イテレータの規約に反したオレオレnth()はやめてくれ
IterMemoなんて名前の構造体にnth()が実装されてればイテレータのnth()と勘違いしてしまう

**デフォルトの名無しさん** · 2022/05/19(木) 21:34:02.60

その前に単純にバグ入りだけど

**デフォルトの名無しさん** · 2022/05/19(木) 21:51:56.08

メモ化と個別機能が完全に分離できている>>152の方が良さげ

**デフォルトの名無しさん** · 2022/05/19(木) 21:55:11.08

このスレだけでなくRust書く人間はコケ前提なのが馬鹿らしい
未知の計算するのに対策してない馬鹿野郎ども

**デフォルトの名無しさん** · 2022/05/19(木) 21:56:15.85

目が覚めろ
目が覚めろ

コケ前提は恥ずかしい

**デフォルトの名無しさん** · 2022/05/19(木) 21:56:34.11

>>159
分離できてねーよw
アホだろ

イテレータ使ったことないのか？

**デフォルトの名無しさん** · 2022/05/19(木) 21:58:30.11

Rust書く人間はレベルが低いと思われても平気なのか？

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

>>156は普通にフィボナッチ数列を順に表示するだけでも常にVecを使ったメモ化を伴うので筋がよくない
>>152はメモ化を付け外し可能で問題点も特に無いようだが

**デフォルトの名無しさん** · 2022/05/19(木) 22:13:58.00

「Rustでドヤりたい素人が犯しがちな12の過ち」
みたいな記事が捗りそう

**デフォルトの名無しさん** · 2022/05/19(木) 22:18:44.85

>>164
関数の設計ができない人の発想

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

>>164
なんでIDコロコロ変えてるの？

**デフォルトの名無しさん** · 2022/05/19(木) 22:27:10.61

>>165
複オジ特有の妄想を一般化するなよ
「複オジがドヤ顔で晒した恥ずかしい勘違い12選」にしとけ
需要ないけどな

**デフォルトの名無しさん** · 2022/05/19(木) 22:29:47.42

こんな数列ごときでヒープ必須の>>156はプログラミングが下手

**デフォルトの名無しさん** · 2022/05/19(木) 22:47:12.76

数列ごときのプログラムしか書けない複製おじさん……

**デフォルトの名無しさん** · 2022/05/19(木) 23:33:01.93

cargo run --releaseで予測した動きをしないコードを書くなよ
速やかにバグを取れ

**デフォルトの名無しさん** · 2022/05/19(木) 23:33:20.92

Rust 1.61.0

**デフォルトの名無しさん** · 2022/05/19(木) 23:35:03.68

このスレの底辺のコーダーもどき全員ゴミ
まともなコードすらかけないでiterが～とか言ってんじゃねえよ
バカども

**デフォルトの名無しさん** · 2022/05/20(金) 00:27:37.05

拗らせくんもいるのか

**デフォルトの名無しさん** · 2022/05/20(金) 00:53:44.89

このスレを見る限りRustプログラマは低レベルの人間ばかり
まともに動きもしないものでああだこうだ言いあってるだけだ

**デフォルトの名無しさん** · 2022/05/20(金) 00:53:59.48

フィボナッチ数列議論スレでやれ

**デフォルトの名無しさん** · 2022/05/20(金) 00:54:42.82

オーバーフローのまともな対処すら知らない馬鹿ばかり

**デフォルトの名無しさん** · 2022/05/20(金) 01:04:06.18

俺が小学生の頃はBASICで整数オーバーフロー考慮したプログラムは書いていた
多倍長整数演算も自分で考案して天文計算もやっていた

このスレの連中は小学生の頃の俺に負けるレベルの奴しかいない
Rustを書く人間はその程度のレベルばかり

**デフォルトの名無しさん** · 2022/05/20(金) 01:16:05.19

エイリアン vs アバター

**デフォルトの名無しさん** · 2022/05/20(金) 02:33:24.77

天文計算なら多倍長じゃなくて浮動小数みたいに指数部と仮数部だけ保持しておくほうがいいだろう

**デフォルトの名無しさん** · 2022/05/20(金) 07:35:06.49

>>177
>>146のオーバーフロー対策をしてみた
これでいい？

fn fibonacci_iter() -> impl Iterator<Item=usize> {
let mut op: Option<usize> = Some(0);
let mut oq: Option<usize> = Some(1);
std::iter::from_fn(move || {
op.take().map(|p| {
op = oq.take().map(|q| {
oq = q.checked_add(p);
q
});
p
})
})
}

fn main() {
for (n, f) in fibonacci_iter().enumerate() {
println!("f({n}) = {f}");
}
}

**デフォルトの名無しさん** · 2022/05/20(金) 08:11:12.19

必要ないOptionまで追加してtake.mapのネストは汚すぎる
事前に設計せずコンパイラ駆動だけで書くと汚いコードになりがち

**デフォルトの名無しさん** · 2022/05/20(金) 08:24:34.35

>>179
勝手に戦えww
複製おじさん vs 100点おじさん

**デフォルトの名無しさん** · 2022/05/20(金) 08:33:57.56

>>168
1レスで晒したこの4つの無知は外せないww

(1) ムーブでビットパターンのコピーは発生しない　-> ムーブ無知
(2) ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない　-> 値渡し無知
(3)さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる　-> Copy無知
(4)Copyのコピーはディープであって高コスト　-> ディープコピー無知

**デフォルトの名無しさん** · 2022/05/20(金) 08:44:11.52

>>182
フラグは必要
それをOptionで簡潔に表現した
批判したいならば代替コードを出すべき

**デフォルトの名無しさん** · 2022/05/20(金) 08:52:03.20

フィボナッチ数列を他の計算の入力として使わないのなら何番目まで必要なのかをusizeとかで受け取ってBigUintのイテレータ返すので十分かな

**デフォルトの名無しさん** · 2022/05/20(金) 08:54:16.47

うげ
俺が出したのは>>185の言う代替案じゃないから
勘違いしそうだから念のため

**デフォルトの名無しさん** · 2022/05/20(金) 09:01:03.34

>>186
うん
今回はオーバーフローの対処をしろと言う>>177のリクエストに応じたのみ

**デフォルトの名無しさん** · 2022/05/20(金) 09:03:09.77

>>182
mapのネストが苦手と言うならば
mapを使わないバージョンも用意したのでどうぞ

fn fibonacci_iter() -> impl Iterator<Item=usize> {
let mut op: Option<usize> = Some(0);
let mut oq: Option<usize> = Some(1);
std::iter::from_fn(move || {
let p = op.take()?;
op = (|| {
let q = oq.take()?;
oq = q.checked_add(p);
Some(q)
})();
Some(p)
})
}

**デフォルトの名無しさん** · 2022/05/20(金) 09:18:53.35

firefoxってどのへんにrust使ってるんだっけ

**デフォルトの名無しさん** · 2022/05/20(金) 10:35:37.22

>>189
さらに汚くしてどうすんのw

**デフォルトの名無しさん** · 2022/05/20(金) 10:55:09.60

>>191
汚いと言うならば同じ動作をするもっと美しいコードを出そう
「汚い」と言う人はいつもコードを出せない人だから負け惜しみで言っているのかと

**デフォルトの名無しさん** · 2022/05/20(金) 10:59:18.09

>>185
unfold使ってた時と同じでフラグという捉え方がコードが汚くなる原因
命名を疎かにせず変数や関数の型を考えよう
そうすればOptionが必要なものと不要なものくらいは区別できるはず
ヒント終わり

コンパイルができた動けばいいだけのコードからは早めに卒業しようね

**デフォルトの名無しさん** · 2022/05/20(金) 11:03:32.49

>>192
君のコードを汚いという人間は一人や二人ではないだろう？
それがなぜなのか？
なぜ汚いと言われるのか？
自分で考えて足掻いてこそ成長するんだよ

**デフォルトの名無しさん** · 2022/05/20(金) 11:08:36.62

>>192
ちなみに汚いコードの反対は汚くないコード
美しいコードである必要はない
実践で重要なのは美しいコードよりも汚くないコードを書くこと

**デフォルトの名無しさん** · 2022/05/20(金) 11:16:04.61

>>193
有無を表現することが必要だからOptionを使うのが最適
Optionを使わずに書けるのならばコードを出そう

>>194
今まで言われたことない
今回言われたから、いつも汚いを連呼しているがコードを出せないダメな人かなと
反論があるならばコードで示そう

**デフォルトの名無しさん** · 2022/05/20(金) 11:26:17.74

>>195
その通りだよ
だから汚くなく、簡素でわかりやすく、無駄をせずに効率も良いコードを>>189に出した
同じ動作と同じ効率でもっと簡素に書けるのならばコードを出してごらん

**デフォルトの名無しさん** · 2022/05/20(金) 11:47:37.20

ベンチも取らずに効率とな？

**デフォルトの名無しさん** · 2022/05/20(金) 11:48:38.99

>>184
その4つは全部並んでたからインパクト強いけど
個々で見るとムーブや値渡しの間違った理解は複オジ特有じゃないからちょっと弱いな

**デフォルトの名無しさん** · 2022/05/20(金) 12:16:58.58

>>196
>今まで言われたことない
すごーいwww
お薬必要ですね