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/21(土) 10:59:08.26

>>224
C++は不要
Cを習得しておけばRustのありがたみがわかる

**デフォルトの名無しさん** · 2022/05/21(土) 11:34:26.44

>>225
演算子の優先順位の話はオライリー本には書いてあるよ
プログラミングを初めて学ぶ人間がRustから始めるべきじゃないというのは完全同意だけど

**デフォルトの名無しさん** · 2022/05/21(土) 11:47:35.41

ぼくはガベージコレクションが嫌いです

**デフォルトの名無しさん** · 2022/05/21(土) 11:50:19.62

オライリー本もヒープとかスタックとか出てくるあたり、CやC++で動的メモリ確保の面倒くささを知ってる人向けだと思う

**デフォルトの名無しさん** · 2022/05/21(土) 11:50:43.88

メモリ管理まわりの勉強はcで必須

**デフォルトの名無しさん** · 2022/05/21(土) 11:56:37.53

逆に考えよう
C→Rustと進むだけで十分であり、何か困ることある？
困ることないよな

**デフォルトの名無しさん** · 2022/05/21(土) 12:04:35.32

ゴミ集めてどうするんだっていう。

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

十分かどうかはさておき
そもそもCをすべきかどうかというと微妙かもしれない
Cしかやってなさそうな人特有の
・変数がたくさんとっちらかった
・変数名が暗号めいてて
・ifやforが多重になってて
・グローバル変数を平気で使っちゃってる
コードみたことあるでしょ
それはそうするしかやり方を知らないから

一方、抽象度の高い言語からやった人は先にそっちに慣れるんで
List(8, 9, 3, 1).sorted.reverse.foreach(print)
こういうふうにスッキリ書けるのを目指してくれる

**デフォルトの名無しさん** · 2022/05/21(土) 12:09:45.76

オブジェクト指向がいちばん大事

**デフォルトの名無しさん** · 2022/05/21(土) 12:10:08.62

格下相手の話だけイキイキするな

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

>>233
それは同感で非常に重要
だから最初に>>223でCとJavaScriptを先に学ぶのをオススメと書いた

**デフォルトの名無しさん** · 2022/05/21(土) 12:39:26.68

ありがたみなんて知る必要ないでしょ
典型的な老害だな

**デフォルトの名無しさん** · 2022/05/21(土) 12:39:58.62

>>221
C++ と java はやったけど C# 必要ですか？

**デフォルトの名無しさん** · 2022/05/21(土) 13:06:24.69

Rustは、プログラミング経験者向けの情報が多い気がするから、PythonとかJavascript辺りをサラッと試してからでも良い気はする。

コンパイルとはとか、型って何？とか。

**デフォルトの名無しさん** · 2022/05/21(土) 14:18:25.43

>>235
それな
自演ネタふりの可能性すらある

**デフォルトの名無しさん** · 2022/05/21(土) 14:45:48.56

いつも同じパターン
質問や相談があると、答えたり情報を出したりせずに、それらをしている人たちをバカにする
コードが出ると、代案コードを出すわけでもなく、とにかく批判のみ行なう

**デフォルトの名無しさん** · 2022/05/21(土) 14:51:09.52

プログラミング初心者は言語知識よりも
プログラミングという行為がどういうものなのか
どういうことを考える必要があるかというメタ認知を得ることが最も重要

メタ認知を獲得するために最も効果・効率ともに高い方法は
考えて・書いて・動かして結果を確認するというフィードバックサイクルをとにかく繰り返し回すこと

初心者は上記のサイクルが回しやすい言語から始めると後々の成長が早い
C/C++/Rustはサイクルを回すために越えなければならないハードルが相対的に高いため
現代では初心者向け言語ではない

**デフォルトの名無しさん** · 2022/05/21(土) 14:57:49.13

>>241
被害妄想はげしくね？
代案も代替コードもそれなりに出てるよね？
それに悪い物を悪い(汚い物を汚い)というためだけに毎回代案を用意する必要なんて全くないよ

**デフォルトの名無しさん** · 2022/05/21(土) 15:08:42.12

意訳:
ぼくちゃんがかいたさいきょうのコードをひはんしないでくだしゃい
ぼくのかんがえたやつがさいきょうなんでしゅから

**デフォルトの名無しさん** · 2022/05/21(土) 15:15:12.95

なでしこ（プログラミング言語）も使ってあげて、、

**デフォルトの名無しさん** · 2022/05/21(土) 15:15:33.24

お前ら>>205みたいなのにも反応してやれよ

**デフォルトの名無しさん** · 2022/05/21(土) 15:46:51.93

>>246
前スレがいしゅつ

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

>>218
そのかかれてるC++入門本のタイトルあげてみろ

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

>>225
お前、>>218 で *計算*の優先順位って書いてるじゃん。
>>225 でしれっと演算子の優先順位にしてんじゃねーよ。

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

お前ら新しい言語勉強する時に本読まないの？
たいていの本には想定する読者ってのが最初のほうに書いているだろ。
現在出版されてるRustの本で他の言語全く使った事ない読者を想定してる本はあるのか？

**デフォルトの名無しさん** · 2022/05/21(土) 17:14:51.81

>>246
Tauriではなくweb-view crateがシンプルで良いと思う

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

>>250
新たなプログラミング言語を学ぶために本を読んだことがないのでRustについてもわからん
わざわざ本を買って学習する人は少数派ではないか？

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

おれは基本は本を読む派だけど、読まない派のほうが多そう

**デフォルトの名無しさん** · 2022/05/21(土) 17:23:04.81

昔は本買うか図書館行くかしかなかったもんね
二十年くらい前からこっちはもう本イランけど
ネットで見れるでしょ何もかも

**デフォルトの名無しさん** · 2022/05/21(土) 17:26:29.76

最近はもっぱら言語公式のチュートリアル。Rustだと「the book」

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/21(土) 17:33:54.80

>>252
必ずしも本でなくてもいいが……。体系的にまとめられた入門用の文書は読むべきだと思う。
Rust に関して言えば >>1-3 で挙げられているような文書があるからありがたく利用させてもらう。

基礎が身についてない段階で詰まるたびにググるみたいな学び方だと個々の情報の断片を
自分の理屈で勝手に (誤った形で) 結び付けてにっちもさっちもいかなくなってるのはよく見る。

**デフォルトの名無しさん** · 2022/05/21(土) 17:59:31.75

確かにこのスレではよく見る
>>112,113

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

複オジは本を読まないのが原因とは違うと思うぞ
本を読んでも自分勝手な理屈を脳内補完してそれが正しいと思い込むタイプ

**デフォルトの名無しさん** · 2022/05/21(土) 18:31:09.43

>>251
実際使ってるの？
github HEADの最終更新11ヶ月前とかだけど

**デフォルトの名無しさん** · 2022/05/21(土) 18:55:12.40

>>259
web-view crateは非常にシンプルで
最初のwebviewビルダーと
JavaScript側からのRustの呼び出しと
Rust側でJavaScriptの実行の三つだけをサポート
学習コストもほぼゼロ
だから更新するようなことがほとんど無い
それでも例えばHTMLのonclick等でRust側を呼び出せてRust側で処理してJSで反映ということが出来てうれしい

**デフォルトの名無しさん** · 2022/05/21(土) 19:02:17.99

>>252
じゃあ >>208 から始まる話題にはお前はおそらく不適切だからレスすんなよ。

**デフォルトの名無しさん** · 2022/05/21(土) 19:12:43.38

>>261
唐突にポカーンだけど
そういった、人への批判は意味がなく荒れるだけで誰の役にも立たないので止めたほうがいいよ

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

たしかに
「そういった人」への批判は意味がなくて、荒れるだけで、誰の役にも立たない

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

「そういった」がかかるのは「人」ではなく「批判」じゃないのかな

**デフォルトの名無しさん** · 2022/05/21(土) 19:30:02.17

元のレスをもじっただけで
唐突に殴りかかってくる人には何を言っても無駄だよと諭してるだけでは

**デフォルトの名無しさん** · 2022/05/21(土) 19:32:49.23

多くの人は良い人たちだが
残念ながらこのスレにも他人を叩いたり言いがかりを付けたりするのが好きなアレな人が紛れ込んでいる

**デフォルトの名無しさん** · 2022/05/21(土) 19:43:36.19

そういうのは反応を見て楽しもうとしてるだけだろうから、無視するしかない

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

>>260
tauriも同じようなもんじゃないの？

**デフォルトの名無しさん** · 2022/05/21(土) 23:40:28.85

今流行のアプリをweb-viewのテストで作ってみたがこんな感じなのか

const HTML: &str = r#"
なぜかHTML部分はセキュリティうんぬん言われて貼れないので略
"#;

fn main() {
struct Fibonacci { index: usize, cur: usize, pre: usize }
let fibonacci = std::sync::Mutex::new(Fibonacci { index: 0, cur: 0, pre: 1 });
let webview = web_view::builder()
.content(web_view::Content::Html(HTML))
.invoke_handler(|webview, arg| {
match arg {
"next" => {
let mut f = fibonacci.lock().unwrap();
(f.index, f.cur, f.pre) = (f.index + 1, f.cur + f.pre, f.cur);
webview.eval(&format!("show({}, {})", f.index, f.cur))?;
},
"exit" => webview.exit(),
_ => unimplemented!(),
};
Ok(())
})
.user_data(()).build().unwrap().run().unwrap();
}

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

MozilaはFirefoxを丸ごとRustに書き換える予定はあるん？
今はまだ一部だけだよねRustになってるの

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

>>270
そうなの？

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

FirefoxはレンダリングエンジンをRustでゼロから作ってるんじゃないの？

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

自分で確かめて
https://github.com/mozilla/gecko-dev

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

servoはまだ実験段階だったと思う

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

>>273
ありがとう～

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

>>270
特にそういう予定はないと思う
servo自体も別に次世代Firefoxを目指してるとかではなく、Rustでwebブラウザを書く実験プロジェクトという感じ
その実験でうまく行ったコンポーネントを徐々にFirefoxに移植していっている

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

アプローチとしては正しい姿なんだろうな

**デフォルトの名無しさん** · 2022/05/22(日) 17:29:35.11

暇を持て余した神々の遊び

servoと言うよりモンスターエンジンだね…

**デフォルトの名無しさん** · 2022/05/22(日) 17:37:14.17

>>270
C++で書かれてる部分は置き換えられるかも知れないけどJSで書かれてる部分までは置き換えしないんでないかな

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

JSとか言ってるのは君だけだと思うよ

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

>>280
FirefoxではC++と同じくらいJS使われてるよ
https://www.openhub.net/p/firefox/analyses/latest/languages_summary

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

JSの部分を置き換えるなんてはなから誰も思ってないってことだと思うが

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

意訳すると「JSで書かれてる部分まで置き換えるとか言ってるのは君だけだと思うよ」かな？
言ってないね

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

>>282
正解

>>283
アホ
JSで書かれてる部分まで置き換えるかどうかとか言ってるのは君だけだと思うよ

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

>>284
じゃ>>280で「言ってる」とか書くな
ボケ

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

>>285
はあ？
JSって言ってるよね？
バカなの？

>>279 JSで書かれてる部分までは置き換えしないんでないかな

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

>>270 が「Firefox を "丸ごと" 書き換える」と言っていたので全部はRustにならないよと伝えたんだけどなんかお気に召さなかった？

**デフォルトの名無しさん** · 2022/05/22(日) 20:16:58.99

>>270が言うのはservoのことでquantumの動機がcssパーサrustで書いたら
安全だったからC++で書かれたコンポーネント置換しよだからjs出る余地ないじゃん。
>>282で終わった話。

**デフォルトの名無しさん** · 2022/05/22(日) 20:17:09.14

そうだね、そんなふうに言われたらシェルスクリプトやMakefileまでrustで置き換えるんじゃないかって思っちゃうよね。

馬鹿なん？

**デフォルトの名無しさん** · 2022/05/22(日) 20:36:16.46

FirefoxはXULのイメージがあってJSも主要な構成要素だと思ってたから変なレスつけちゃったね
皆さんの機嫌害しちゃって申し訳ない

**デフォルトの名無しさん** · 2022/05/22(日) 20:54:23.92

よく見たらID変えて暴れてるやつまだ居座ってるのか。

>>290
XULはだいぶ前に死んだよ。
XULRunnerが単体で利用困難な問題が解決できなくて存在意義を失った。

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

>>291
XUL完全になくなったの？
XBLは完全に消えたって聞いたけどXULは細々と生き残ってるものだと思っていた

**デフォルトの名無しさん** · 2022/05/23(月) 01:12:40.07

>>290
ほんと反省しろよ

**デフォルトの名無しさん** · 2022/05/23(月) 02:27:31.54

反省してま～す

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

>>189
おまえら全員そうだがフィボナッチ数列でusize固定はおかしいだろ
コード自体は問題ないが <T: Zero + One + CheckedAdd> を付けろ
あとは0と1をT::zero()とT::one()へ置き換えればi8型からBigUintまで何でも動作するようになる
https://play.rust-lang.org/?edition=2021&gist=929f3df48db39182558dfad6fe8d1cda

さらに今回はfrom_fn()利用をそのままsuccessors()利用へ変換できるので見やすくなる
fn fibonacci_iter<T: Zero + One + CheckedAdd>() -> impl Iterator<Item = T> {
let mut oq = Some(T::one());
iter::successors(Some(T::zero()), move |p| {
let q = oq.take()?;
oq = q.checked_add(p);
Some(q)
})
}
ちなみにCloneを要求しないためBigIntなどでも無駄なコスト増とならない

>>202
そのコードは暗黙のコピーが発生している
from_fn()使用版のコードはcurrがキャプチャ変数なので「let n = curr?;」でコピー発生
successors()使用版のコードはクロージャ引数「|&curr: &usize|」の「&」でコピー発生
usizeならば問題はないがBigIntなどでそのコードは動かないので劣る

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

暗黙のコピー発生って気にするべき？
!Copyならコンパイルエラーになるしこれまで気にしたことなかった

あとcurrはmoveでキャプチャされるからcurr?で発生するのはmove(とそれに伴うmemcpy)だけど、moveのコストも気にすべき？

**デフォルトの名無しさん** · 2022/05/23(月) 20:00:24.28

>>296
それは逆
そのキャプチャされた変数はクロージャが呼ばれるたびに何度も使われる
つまりムーブされてはいけない、つまりムーブ禁止となる
したがって n = curr? で currの中身は nへムーブされずコピーとなる

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

>>297

**デフォルトの名無しさん** · 2022/05/23(月) 20:12:20.25

>>296
必ずCopy前提の型しか扱わないときは気にしなくていい
しかし今回は!Copyの数値型でも動かないと話にならないからコピーが起きるコードを避けないと

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

>>299
!Copyの場合はコンパイルエラーになるからわざわざ人間が注意を払う必要はないと思うが、気にすべき？
usizeしか使わなくてもTに置き換えた場合を想定してコードを書くべきということ？

**デフォルトの名無しさん** · 2022/05/23(月) 20:27:05.01

>>300
u128を使ってもf(200)がオーバフローするような今回の案件でCopy型が前提のコードはよくない
案件次第だけど今回はコピーの有無を気にすべき案件

**デフォルトの名無しさん** · 2022/05/23(月) 20:43:27.72

>>295
自分のレスに他人のふりしてレスするキチガイ汚コーダーこと複オジさんちぃーすっ

**デフォルトの名無しさん** · 2022/05/23(月) 20:49:26.67

>>296
それはmoveの意味を間違えているぞ
>>202のcurr?はコピーが発生する
FnOnceじゃないんだからcurrの値がmoveされたら次に使えなくなる
move禁止となりCopy型ならコピーが発生し!Copy型ならエラーとなるコード

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

>>301
copyを気にするのではなくusize or BigIntのどちらを使うべきか意識すべきと解釈した
usizeで良い場合はcopyは気にせずして良い

>>303
FnOnceかFnMutかFnかは関係なくて
moveなclosureでキャプチャしたらmove発生するよ
moveでキャプチャされた値をクロージャの中でさらにmoveできるか、refしかとれないかがFnOnceとFnの違い

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

https://www.reddit.com/r/rust/comments/3wubj0/comment/cxzlvt4/

num_traitsによるジェネリクスは絶対の正解ではないから適当なところで諦めようね

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

>>304
それは別の話でその違いを理解できていないようにみえる
クロージャへのmoveはクロージャが作られた時に終っていてクロージャ内のコードでの動作なは関係ない
間違っているのは後者の話でこの部分

>>296
> curr?で発生するのはmove(とそれに伴うmemcpy)

curr?でmoveは起きない
curr?で起きるのはコピーである(!Copy型ならエラー)

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

>>296
コピーもmoveも同じでそれがボトルネックかどうかが重要
数値プリミティブの場合はコピーを他の方法に変えたところでボトルネックが解消されることはまずないから気にする必要はない

BigUint前提ならVecと同じでmoveやクローンやのオーバーヘッドはそれなりに気にした方がいい
逆に現実的にはオーバーフロー考慮する必要がなくなるからCheckedAddが余計なオーバーヘッドになる

特性の違う物をジェネリック等でまとめたほうがいい場面なのかそれぞれ別の実装を用意したほうがいい場面なのか判断できることが大事

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

>>307
それは間違ってるぜ
BigUintのchecked_add()は常にSomeを返すためにチェックとSomeは消えてオーバーヘッドとならない
さらにRustのジェネリックは各型にmonomorphizationされるためジェネリックで書いてもプリミティブ型やBigUint型のコードはそれぞれに最適化される

**デフォルトの名無しさん** · 2022/05/23(月) 22:04:52.01

ヒント:
Ratio<T> where T: Integer + Clone + CheckedAdd + CheckedMulは>>295の条件を満たす

**デフォルトの名無しさん** · 2022/05/23(月) 22:25:54.83

fibonacci_iter::<Ratio<u8>>()すると
ちゃんと最後233で止まるのね
ジェネリック凄い

**デフォルトの名無しさん** · 2022/05/23(月) 22:34:47.31

ククク……RatioのCheckedAddの実装を見ても果たして同じことが言えるかな

**デフォルトの名無しさん** · 2022/05/23(月) 22:37:22.49

汚染が始まった！

**デフォルトの名無しさん** · 2022/05/23(月) 22:55:06.68

>>311
たしかにRatioの実装が悪いな
まずAddと同様に
if self.denom == rhs.denom {の分岐をし
そして1の場合は
self.numberとrhs.numberでchecke_addするくらいはしないとな

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

ジェネリックに書いてもRatio専用コードを書いても
どちらもRatioの実装を使わざるをえないのだから同じ結果となる

そしてRatio専用コードを書こうとしても外部からは工夫のしようがないため
ジェネリックからコンパイル時にモノモーフィゼーションされるコードと全く同じになる

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

このスレごちゃごちゃした書き込み多すぎ

**デフォルトの名無しさん** · 2022/05/24(火) 00:53:51.91

各型を個別に確認しないと良いか悪いか判断できないならジェネリックにしちゃだめでしょ

**デフォルトの名無しさん** · 2022/05/24(火) 01:46:13.03

>>316
そんな個別に確認しなきゃいけないことは起きないから大丈夫
Rustの標準ライブラリも大半はジェネリックに書かれている

**デフォルトの名無しさん** · 2022/05/24(火) 07:59:54.71

>>307
>特性の違う物をジェネリック等でまとめたほうがいい場面なのかそれぞれ別の実装を用意したほうがいい場面なのか判断できることが大事
禿同だわ
コードパズルやってるやつにいつも感じる違和感の原因はこれだな
こういう能力って何て言うんだろ？

**デフォルトの名無しさん** · 2022/05/24(火) 08:06:11.71

>>318
でも今回の件の数列ならばジェネリックが正解やろな
わざわざ各数値型に個別に実装しなくて済む
分けるほうが不自然で手間

**デフォルトの名無しさん** · 2022/05/24(火) 08:45:23.72

男の人って気持ち悪い…
どうして少女をそんなに汚したがるの？
お母さんに悪いとわおもわないの？

**デフォルトの名無しさん** · 2022/05/24(火) 08:52:13.15

>>318
広く言えば設計能力
狭く言えば実装パターンの選択能力

総合的な能力だから一朝一夕には身に付かない
実装パターンの整理が進んでないRustだと特に

**デフォルトの名無しさん** · 2022/05/24(火) 11:37:27.58

KISS原則だろ

**デフォルトの名無しさん** · 2022/05/24(火) 19:12:35.28

>>202のlet n = curr?;の部分を
>>189はlet n = curr.take()?;としてコピーになるのを回避しているだけかと思ったら
両者が全く異なるアルゴリズムを採用していることに気付いた
>>202のアルゴリズムだとどうやってもコピーを避けられないから詰んでるね

**デフォルトの名無しさん** · 2022/05/24(火) 22:16:43.51

prev, currの状態管理だとcurrの値をprevに代入するのと戻り値として使うのと2箇所に必要になるからね
curr, nextで管理すればいい

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

アルゴリズムというほど大げさな話ではないだろ
f(n)を求めるnext()が呼ばれた時に

>>189は内部にf(n)とf(n+1)を持っていて、足し算してf(n+2)を作る
そして内部にf(n+1)とf(n+2)を残して、f(n)を返す

>>202は内部にf(n-1)とf(n)を持っていて、足し算してf(n+1)を作る
そして内部にf(n)とf(n+1)を残して、f(n-1)は捨てて、f(n)をコピーして返す
つまりムダ

>>324
同意