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/31(火) 10:19:23.69

>>407
全部プリプロセッサで完了するCみたいなイメージじゃね
知らんけど

**デフォルトの名無しさん** · 2022/05/31(火) 14:58:10.34

回答ありがとう

>>415
clapで環境変数読むの行けるのか、知らなかった
argfileはコマンドラインオプションをファイルに書くと読み込んでくれる感じなのかな

>>416
なるほど、環境変数自体を.envファイルに書いてもらってそれをコマンドラインオプションに読み替えるわけね
これは良さそうだ

**デフォルトの名無しさん** · 2022/05/31(火) 20:23:20.27

env feature指定すると扱える
あと今時の形式>>416ではderive featureも必須

**デフォルトの名無しさん** · 2022/05/31(火) 21:26:01.43

>>404
Dust言語
あると思います

**デフォルトの名無しさん** · 2022/06/03(金) 21:24:55.91

配列の中で移動コピーする方法を教えてください
例えば
移動前 [X, X, X, X, 4, 5, 6, 7, 8, 9]
移動後 [4, 5, 6, 7, 8, 9, X, X, X, X];
Xは任意の値で構わないです
可能ならばstable safeでお願いします

**デフォルトの名無しさん** · 2022/06/03(金) 21:51:48.48

複おじか？お前

**デフォルトの名無しさん** · 2022/06/03(金) 21:58:58.40

>>421
xs.rotate_left(4);

**デフォルトの名無しさん** · 2022/06/03(金) 22:49:16.06

コピーとあるからcopy_within(4.., 0)でいいんじゃないか
rotate_leftだと大きな配列で後方と前方の間の小さいサイズのコピーでも全体のコピーが発生して無駄

**デフォルトの名無しさん** · 2022/06/03(金) 23:22:12.53

なるほど、任意の値で構わないってのはそういうことだったのか

**デフォルトの名無しさん** · 2022/06/03(金) 23:55:24.30

ありがとうございました
ところで文字列にはfindメソッドがあって便利なのですが
指定した値が配列の中で前から何番目にあるかを返すメソッドはありますか？

**デフォルトの名無しさん** · 2022/06/04(土) 00:13:56.42

>>426
slice::iter::position

**デフォルトの名無しさん** · 2022/06/04(土) 00:40:32.70

positionでもfindでも行ける

let buf = b"abc\ndef\n";
assert_eq!(Some(3), buf.iter().position(|&b| b == b'\n'));
assert_eq!(Some(3), (0..buf.len()).find(|&i| buf[i] == b'\n'));

文字列でのこの簡潔さと比べるとスライス直結findが欲しくなるのはわかる

let str = "abc\ndef\n";
assert_eq!(Some(3), str.find('\n'));

**デフォルトの名無しさん** · 2022/06/04(土) 00:48:39.66

bikeshed

**デフォルトの名無しさん** · 2022/06/04(土) 01:04:34.73

str::findは部分列も対応
let str = "abc\r\ndef\r\n";
assert_eq!(Some(3), str.find("\r\n"));
なぜslice::findを作らなかったのだろう？

**デフォルトの名無しさん** · 2022/06/04(土) 09:04:26.92

出た
汚コード

**デフォルトの名無しさん** · 2022/06/04(土) 09:19:04.11

Rustの仕様自体が汚いんだよ

**デフォルトの名無しさん** · 2022/06/04(土) 09:34:38.78

汚コードでもいいやん
反面教師になるんだから

ただし単発の短いコードに限る
フィボナッチ汚コードのペタペタ連投みたいなのはもう勘弁

**デフォルトの名無しさん** · 2022/06/04(土) 09:56:15.67

汚コードなの？初心者だからマジわからん
docのstd::slice::iter::position をみたら似たようなコードだったけど

**デフォルトの名無しさん** · 2022/06/04(土) 10:11:21.31

>>430
sliceから部分sliceを探索する頻度が文字列から部分文字列を探索する頻度に比べて圧倒的に低いから、じゃないの
C++のSTLも文字列にしかメンバ関数としてのfindは無いし、これも同じ理由ではないかな

**デフォルトの名無しさん** · 2022/06/04(土) 11:23:20.02

Rustのエラー表示すばらしいなほんとに
めちゃくちゃ楽だわな

**デフォルトの名無しさん** · 2022/06/04(土) 12:01:38.84

いつも汚コード言ってるやつはキチガイだから無視しとけ

>>430
部分スライスに対してもiterの代わりにwindowsを使えば同じようにpositionで部分文字列findと同じ結果を得られる

let buf = b"abc\r\ndef\r\n";
assert_eq!(Some(3), buf.windows(2).position(|b| b == b"\r\n"));

**デフォルトの名無しさん** · 2022/06/04(土) 12:02:08.90

エラー表示が出ている時点で(ry

**デフォルトの名無しさん** · 2022/06/04(土) 12:43:02.16

bikeshed bikeshed bikeshed

**デフォルトの名無しさん** · 2022/06/04(土) 13:12:11.67

文字列のPatternに相当するものがsliceになないからでは

**デフォルトの名無しさん** · 2022/06/04(土) 13:40:33.24

>>434
汚いかどうかの判断ができるようになるには言語に限らずその分野である程度の経験が必要

汚いなと思ってたコードが慣れるとそうでもなくなる逆の現象もある

**デフォルトの名無しさん** · 2022/06/04(土) 13:47:22.44

汚コード公式汚コードですわ～！

**デフォルトの名無しさん** · 2022/06/04(土) 13:57:36.96

>>434
公式exampleと同じなのでもちろん汚コードではない
もし何か問題がある場合は必ず誰かが代わりのコードを示すので大丈夫
汚コード連呼を相手にする必要なし

**デフォルトの名無しさん** · 2022/06/04(土) 14:11:57.60

こんなスレに質問しに来る初学者なんてものは最初から存在しないんだろうな

**デフォルトの名無しさん** · 2022/06/04(土) 14:23:56.41

ん？
「初心者だからわからん」というのが汚コーダーの自演だろってこと？

**デフォルトの名無しさん** · 2022/06/04(土) 14:34:25.51

そうだよ

**デフォルトの名無しさん** · 2022/06/04(土) 14:39:18.00

複クンはね
みんなに見てもらいたいんよ
つきあってあげてよ

**デフォルトの名無しさん** · 2022/06/04(土) 15:03:39.84

なるほど言われてみればそうかも
流れ的に>>208なんかも怪しいな
気をつけよう

**434** · 2022/06/04(土) 15:21:18.99

自演臭くなるからアレなんだけど
暇潰しに公式ドキュメントと照らし合わせて疑問に思ったから書き込んだだけで
ただの通りすがりだからね

**デフォルトの名無しさん** · 2022/06/04(土) 15:39:42.64

>>449
あれは何もかも自演に見えてくる病気な人による連投だから気にする必要なし
何でもかんでも自演だ！汚コードだ！と言うダメな人

**デフォルトの名無しさん** · 2022/06/04(土) 16:10:13.56

書いてあるコードよりましなコードを出せずに汚コードって呟くしかない可哀想な人は暖かくスルーしてやってくださいな

**デフォルトの名無しさん** · 2022/06/04(土) 16:13:38.80

>>448
汚いというならオマエのコードを出せとイキってたのに
実際にコードが出てきてダンマリ決め込んだタイミング・・・

ありえそう
変な初心者が来たなとは思ってたが・・・

**デフォルトの名無しさん** · 2022/06/04(土) 16:30:17.39

汚コードを連呼してる人が初めて出したコードがこれ。>>202
しかしアルゴリズムに問題があってフルボッコにされて撃沈。
汚コードを連呼の人が普段コードを示せない理由が判明してしまった事件。

**デフォルトの名無しさん** · 2022/06/04(土) 21:35:57.57

うわーこれ確定じゃん
複くんRustなんかやめてネトサポやれば？

**デフォルトの名無しさん** · 2022/06/04(土) 23:04:11.48

>フルボッコにされて撃沈。
主砲「Copyはディープで高コストだから避けるべき」発射！ ==> ドッカーンwww撃沈www

**デフォルトの名無しさん** · 2022/06/04(土) 23:12:57.28

真面目に書いとくとusizeみたいな数値プリミティブの場合はCopy前提で全く問題ないよ
気になる人はベンチにかけてね

**デフォルトの名無しさん** · 2022/06/04(土) 23:38:03.39

>>456
一般的にはその通り
しかし今回はusizeだとすぐ溢れるからBigUintなどを見越してのコードの話
>>202への批評内容はいずれもusizeでしか通用しないアルゴリズムをわざわざ採用したという点
一方で>>202が汚コードとみなした元のコードはusizeでもBigUintでもちゃんと動作するアルゴリズムになっていた

**デフォルトの名無しさん** · 2022/06/04(土) 23:52:08.43

汚コード連呼厨は信頼できない
代わりのコードをいつも出せない
珍しく出してきたら元より劣化してた

**デフォルトの名無しさん** · 2022/06/04(土) 23:57:58.57

最初のコードでだいたいあってるんですよ
それを君がずっと引っ掻き回してるだけ
最初からあるんだからわざわざ出す必要もない

>>427で終わってた話を>>428で誰も求めてないfindで書き直したり

**デフォルトの名無しさん** · 2022/06/05(日) 00:16:50.25

毎週This Week in Rustのリンクでも貼ればこのくだらない流れは終わるのだろうか

**デフォルトの名無しさん** · 2022/06/05(日) 00:46:34.90

ところでスライスへのfindメソッドなどの後付けはRustのorphan ruleを犯さずに可能なの？

**デフォルトの名無しさん** · 2022/06/05(日) 04:00:56.97

trait定義すればできる

**デフォルトの名無しさん** · 2022/06/05(日) 09:25:11.96

> 誰も求めてないfindで書き直したり

そもそも、誰ももとめてない
「ぼくのかんがえたさいきょうふぃぼなっちいてれーた」
をどんだけ貼り付けたんだろうな彼はｗ

誰も求めてないものを必死でシコってるからうんざりなんよ

**デフォルトの名無しさん** · 2022/06/05(日) 10:25:57.06

複クンはなぜ汚いと言われるのか理解しないね
言語やライブラリの制約で避けられないような汚なさならここまで言われない

**デフォルトの名無しさん** · 2022/06/05(日) 10:34:37.11

シンプルに意図が伝わりやすい書き方が他にあっても
ぼくのかんがえたさいきょうのシコシココードを我慢出来ずに開陳しちゃうからここが汚部屋になる

**デフォルトの名無しさん** · 2022/06/05(日) 10:48:55.83

findバージョンで答えようとしたところで
>>427のレスがあったから「findでも行ける」に方向転換したんじゃね？
幼稚園児と同じでママン達に誉めて欲しかったのに
汚いと一蹴されて涙目

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

>>460
ブログへのリンクやアップデートはややマンネリ気味だけど
今週のcrateはいつもチェックしてる

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

>>467
そういう話をしたいのにRustと関係ない話や批判で荒らす連中がうざい
Rustの話ならば最新動向から初心者の質問まで何でも歓迎
しかし他人叩きしている連中は邪魔

**デフォルトの名無しさん** · 2022/06/05(日) 17:36:49.26

可読性や汎用性を犠牲にしてもfindがpositionより優位に速いとか
ユースケース次第ではデメリットを補うだけのメリットがあるなら多少汚くても受け入れられる
フィボナッチの>>202と比較対象の>>181や>>189も同様

**デフォルトの名無しさん** · 2022/06/05(日) 17:53:32.33

速度はベンチを取ってから
ユースケースは具体的に示してから
そういうことを主張してください

そして本当に互いのやり方にメリデメがあると認めているのなら、>>295のような他人叩きはやめましょうね

**デフォルトの名無しさん** · 2022/06/05(日) 18:25:46.65

まーたふぃぼなっち言ってるｗ
バカのひとつ覚えすなあｗ

**デフォルトの名無しさん** · 2022/06/05(日) 18:50:30.04

>>470
その>>295は他人叩きではないだろう
そのアルゴリズムではBigIntで無駄なコピーが発生するというRustで気をつけるべき技術的な問題の指摘にみえる
そして回避コードもきちんと示しているのでそういう書き込みは歓迎

**デフォルトの名無しさん** · 2022/06/05(日) 21:53:01.43

>>470
何のメリットもなく汚くしてるだけだから受け入れられないという話だったんだが

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

ジェネリックのフィボナッチや
ジェネリックのカウントアップみたいな
架空のユースケースの話題はもういいよ

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

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=41e1df59aeafe6f45fccaa192941d6d1

iter1とiter2は>>295からの引用
Ryzen 7 3700Xで計測
ジェネリクスへのこだわりを捨てればこのくらいは速くできるよ

fib_iter1 time: [7.2754 ms 7.2824 ms 7.2907 ms]
Found 2 outliers among 100 measurements (2.00%)
1 (1.00%) high mild
1 (1.00%) high severe

fib_iter2 time: [7.8536 ms 7.8678 ms 7.8818 ms]

fib_biguint time: [4.9757 ms 4.9784 ms 4.9812 ms]
Found 5 outliers among 100 measurements (5.00%)
5 (5.00%) high mild

Playgroundでもベンチマークできればいいのになあ

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

「RustとC++を学ぼうと思ってるプログラミング初心者です。」(架空)

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

どの場でも同じだが
「技術的な話題と技術的な指摘」
「他者の話題と他者への攻撃」
この違いがわからず後者を行なうダメ人間のせいで場が荒れる

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

>>475
それは流石に比べる対象が違うんじゃ？
ノンジェネリック版もイテレータを返すか
ジェネリック版をフィボナッチ数を直接返すようにして比べないと

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

>>475
playgroundみたいな環境でベンチマークやれたとしても結果が安定しないのでは

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

>>475
純粋にジェネリックか否かの比較をしたいならばadd_assignとaddの違いなども含めて条件を全て揃えたほうがよい
元がiter::successorsを使っているならば非ジェネリック版も同じくそれで揃えてみてはどうか

**デフォルトの名無しさん** · 2022/06/05(日) 23:17:38.06

>>478
>>480
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=4f477ec7bc08ea9f61f565c00beb0d19

ジェネリックなほうをできる限り揃えたけどこれでいいかい？
CheckedAddでadd_assignする方法だけ無さそうだったからアレになってるけど

fib_generic time: [7.4054 ms 7.4164 ms 7.4275 ms]
Found 1 outliers among 100 measurements (1.00%)
1 (1.00%) high mild

fib_biguint time: [4.9527 ms 4.9591 ms 4.9655 ms]

**デフォルトの名無しさん** · 2022/06/05(日) 23:34:45.61

>>477
> 後者を行なうダメ人間
そういうのは一定数いるからスルーしてくださいな...

**デフォルトの名無しさん** · 2022/06/06(月) 00:32:35.96

イテレータで計測してみたけど
>>295のoption::takeだとcloneしても速度変わらないな
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=283e5cd13159cab00fcc68d56952df01

**デフォルトの名無しさん** · 2022/06/06(月) 02:33:06.91

>>483
そういう比較はそれ以外の部分のコードを揃えないと何が要因なのか判断できないよ

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

Rustってフィボナッチ専用言語みたいだな

**デフォルトの名無しさん** · 2022/06/06(月) 12:48:39.09

>>481
addがchecked_addになることで最適化が妨げられてるみたい

結局複オジが言ってたことは全部間違いだった

**デフォルトの名無しさん** · 2022/06/06(月) 14:47:49.79

premature optimizationとpremature abstructionの典型例

・具体的なユースケースを想定しない
・トレードオフを考えない
・誰も求めてない抽象化
・計測を伴わない思い込み最適化

コードの汚さと悉く間違った主張の根っこは同じ

**デフォルトの名無しさん** · 2022/06/06(月) 15:32:14.02

複オジのおかげでいろんな教訓が再認識できて良かったね
反面教師の鑑
めでたしめでたし

**デフォルトの名無しさん** · 2022/06/06(月) 15:53:42.58

>>487
なるほど
「早すぎる抽象化 × 早すぎる最適化 => 汚コード」ってことか
これは身に覚えがありまくる

**481** · 2022/06/06(月) 16:16:13.39

>>486
正確に言えば
問題はCheckedAdd::checked_add()はselfもotherも参照で取るから、BigUintだと内部で1回clone()されてしまうということなのよね
一方でadd_assignは(桁があふれない限り)in-placeにやるから、その分のコストが発生しない
だから(compiler optimizationという意味での)最適化以前の問題だよ

https://mevius.5ch.net/test/read.cgi/tech/1509028624/153
↑のコードも参考にどうぞ
C++で二項演算子をオーバーロードするときのイディオムです
これを思い出しながら書きました

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

>>490
ソース見るところ勘違いしてた
確かにaddでも&self使えばclone入るからchecked_add並みに遅くなった

checked_addにownedのselfを取るバージョンが追加されれば改善するだろうけど
trait定義からして対応するつもりのないユースケースかもね

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

>>491
CheckedAddAssignを導入すれば全て解決しそうだな

**デフォルトの名無しさん** · 2022/06/06(月) 17:23:25.42

必要ならextension traitを書けばいい
そこまでしてジェネリックにする価値があるとは思えないけど

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

リーナスさんから受けたパニックのありがたい指摘って結局どうなったん？

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

放置されてんじゃないの？
コンパイラがパニック起こさないように変えられたって聞かないし

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

パニックにならないオプションくらい作ってもいい気もするけどね

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

パニック自体はもう１年前くらいに修正済み
今はv7 patchまで来ていて大きな懸念も出ていないから
そろそろマージされてもおかしくはない

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

リーナスレベルに行く前に誰も問題視してなくて指摘もされてないんだろうか
みんなガバガバなんだな
panic前提のコーディング

**デフォルトの名無しさん** · 2022/06/06(月) 22:44:51.98

try_reserveはstabilizeされてるよ

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

>>498
リーナスが最終承認だけするイメージなんかな？
LKML読めば分かるけど、普通にパッチ投げるたびに突っ込んでくるよ

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

ジェネリックフィボナッチと同程度にどうでもいい

**デフォルトの名無しさん** · 2022/06/06(月) 23:15:40.43

>>481
1.5倍も差があるのは妙だな
Rustでは最適化されるのでジェネリックで書こうがそんな差は出ないはず
そのベンチマークの仕方がおかしい可能性があるので
ジェネリックか否か、check_addか＋か、Option利用か否か、など5つのコードで順に調べてみた

ベンチマーク使用コード
https://gist.github.com/rust-play/18d303c3ec79c19c4285ed190e5b2562
(1) ジェネリック + checked_add + Option + successors 版: 元の>>295と完全に同じコード
(2) BigUint + checked_add + Option + successors 版: (1)のTをBigUintへ
(3) BigUint + add + Option + successors 版: (2)のchecked_addを'+'へ
(4) BigUint + add + Option削除 + successors 版: (3)の変数Optionを削除
(5) BigUint + add + Option削除 + from_fn 版: (4)のsuccessorsをfrom_fnへ

結果
test bench_1 ... bench: 619,527 ns/iter (+/- 18,257)
test bench_2 ... bench: 620,293 ns/iter (+/- 23,787)
test bench_3 ... bench: 624,149 ns/iter (+/- 24,388)
test bench_4 ... bench: 626,810 ns/iter (+/- 20,343)
test bench_5 ... bench: 619,675 ns/iter (+/- 30,977)

結論
いずれも誤差の範囲でほぼ同一結果
Rustではジェネリックで書いても最適化される
BigUintでchecked_addやその結果のOptionを使っても最適化される

したがってi8からBigUintまで任意に動作する>>295のジェネリックコードで問題なし、となる

**デフォルトの名無しさん** · 2022/06/06(月) 23:58:37.28

>>502
Rust凄いな
ジェネリックもOptionも何でも最適化してくれるとは改めてRustの素晴らしさを実感

**デフォルトの名無しさん** · 2022/06/07(火) 00:13:51.07

>>502
そのやり方で差が出ないのはchecked_addと同じようにcloneが発生するタイプのaddが使われてるからだよ
ジェネリックにしても差が出ない場合もあれば差が出る場合もあるということ

**デフォルトの名無しさん** · 2022/06/07(火) 00:16:51.98

>>502
やはり同じになったか
既に>>478が指摘しているように元のコードとイテレータ同士で比較ベンチを取ろうとしないから>>475を怪しいと思ってた
ちゃんと比較ベンチすれば最適化されて同じ速さになることを知っての狼藉だったりして

**デフォルトの名無しさん** · 2022/06/07(火) 00:17:18.96

https://gist.github.com/rust-play/8caca28378745b36aaba5358d2a54fe8

test bench_1 ... bench: 426,714 ns/iter (+/- 5,563)
test bench_fast ... bench: 201,510 ns/iter (+/- 2,926)

Criterion の使い方が分からなかったのかな

**デフォルトの名無しさん** · 2022/06/07(火) 00:19:44.22

>>504
どういうこと？
具体的に>>502の各コードよりも速いコードを書けるってこと？
そのコードを示せない限り>>502のベンチ結果を覆せない

**デフォルトの名無しさん** · 2022/06/07(火) 00:35:03.04

>>506
君は全く別の問題にすり替えて誤魔化している
>>502のようにイテレーター同士でベンチマークをとるべき

**デフォルトの名無しさん** · 2022/06/07(火) 00:38:00.86

まーたすがすがしいまでの自演だなぁ

**デフォルトの名無しさん** · 2022/06/07(火) 00:39:26.17

>>507
>>504の指摘の何が分からないの？

**デフォルトの名無しさん** · 2022/06/07(火) 01:10:53.92

https://gist.github.com/rust-play/bde9b95f9bfe4de77fad841db30222c7

test bench_1 ... bench: 420,671 ns/iter (+/- 53,102)
test bench_fast ... bench: 219,091 ns/iter (+/- 1,147)

こんな汚ないことしてまでイテレータになんかしたくないんだけど
どうせ次の文句も大体予想付くし

**デフォルトの名無しさん** · 2022/06/07(火) 01:35:52.48

この件はRustにとって重要なことだから口を挟むが、
Rustではジェネリックで書いてもmonomorphizationによって各型で書いた時と同じコードになる。
だから標準ライブラリの大半はジェネリックに書かれている。
そしてSomeなどのOptionは最適化できる時は綺麗に消えるため、
BigIntのchecked_addのように常にSomeを返す時も最適化でOptionは消えると考えられる。
いずれも抽象的に書けるのに動かすとC並に速いというRustの長所である。

つまり、>>502の結果が出たことはそれらが実証付けられたことになる。

しかし、以前からジェネリックは無駄とか遅いとかRustの長所に反する主張をする人がいるので気になっていた。
今回もRustのジェネリックは遅いと主張するために、
>>506のように、完全に異なるもの同士を比較したり、
>>511のように、Rcを返すという別仕様のものにしてまで、ジェネリックは遅いと主張し出した。
反Rustか反ジェネリックの立場なのかもしれないが、そういう捏造や詐欺のようなことはよくない。

**デフォルトの名無しさん** · 2022/06/07(火) 01:49:10.77

>>512
同意

**デフォルトの名無しさん** · 2022/06/07(火) 03:36:34.68

>>512
ジェネリクスが無駄だの遅いだのはコード生成の話ではなくてコードのメンテナンスコスト含めた全体の話では

例えば今回ジェネリックなコードで無駄なcloneを避けるためには CheckedAddAssign といった trait を用意し、各整数型に実装するという余計な手間が発生する
また、各整数に追加のtraitを実装したとしても固定長の整数型ではすぐに桁あふれしてしまうから、実質BigUintの実装しか意味がないものになる
だったら最初からジェネリックにせずBigUintで実装するか、BigUintやBigIntといった桁あふれしない型だけを対象にすればよい

ジェネリクスの良さを語りたいならもっと良い例があるんじゃないの

**デフォルトの名無しさん** · 2022/06/07(火) 07:03:55.78

>>511
そのコードはイテレータ内部で無理にunwrapしているためこれだけでpanicしてしまう
let mut iter = fibonacci_biguint_iter();
let first = iter.next();
let second = iter.next();
実行結果
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:23:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
これでは反証コードになっていないので
ちゃんとimpl Iterator<Item = BigUint>を返すコードを書いたほうがいい

>>514
その無駄なcloneとは何？
ベンチ>>502のジェネリックコードを含めた5つのコードを見てみたが無駄なcloneは見当たらなかった
それらよりもベンチで速いコードが出てこない現状をみると無駄は無いのではないか
あと、BigUintを使うまでもない需要も多いのだからジェネリックに書かれたコード一つで十分と感じる

**デフォルトの名無しさん** · 2022/06/07(火) 08:13:15.84

>>503
それはLLVMのおかげじゃない？
他言語でできないRustならではの優位点てあったっけ？