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/28(土) 23:58:46.72

>>370
yieldを使うとIteratorの実装が楽になる？
from_fn()のようなfrom_generator()を用意するのかな

**デフォルトの名無しさん** · 2022/05/29(日) 01:25:03.17

またイテレータの話してる……

**デフォルトの名無しさん** · 2022/05/29(日) 01:35:28.37

結局イテレータを作るには構造体か何かを用意してnext()実装するしかないぜ
それが面倒ならfrom_fnやunfoldなどの汎用イテレータ作成関数を使うしかないな
こんな感じか

fn iter_from_generator<G: Generator + Unpin>(mut generator: G) -> impl Iterator<Item = G::Yield> {
iter::from_fn(move || {
match Pin::new(&mut generator).resume(()) {
GeneratorState::Yielded(n) => Some(n),
_ => None,
}
})
}

fn main() {
let one_two_three = || {
yield 1;
yield 2;
yield 3;
};
for n in iter_from_generator(one_two_three) {
println!("{n}");
}
}

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

複クンなんですぐここに貼り付けてしまうん？
それお母さんに見てもらうだけでは不満なん？

**デフォルトの名無しさん** · 2022/05/29(日) 16:18:25.46

すまんが、関数とジェネリックについてわかんないんだけどさ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c548f2825b9f164eeabdd479c4950484
これってなんで動かないん？

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

>>375
<T>という型情報だけじゃT{b:1}が正しい式か分からないから
値の内容にまで踏み込みたければtrait boundを付けてtraitが許す範囲内でやるしかない

**デフォルトの名無しさん** · 2022/05/29(日) 16:52:27.60

>>375
Tに渡されるのがいつもAだとは限らないからrustはエラーを出すんや
c++だったらエラーにならないが

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

そういうことなのか！ありがとう！
だからサンプルコードみんなTを引数で受け取って戻値Tを返してるのばっかなのか

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

「(i64 の) 1 から変換可能な型」という制約を付けるのであればたとえばこんな感じかな。

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=73e1d04ceeb2c0aff1dae461126dfb6e

**デフォルトの名無しさん** · 2022/05/29(日) 18:07:23.25

>>378
Tを引数に取らずにTを返すことも一般的に可能
その場合もTに何らかのトレイト境界を付けてそのトレイトのメソッドを呼ぶ形で実現する
fn c<T>() -> T {
T { b: 1 }
}
↓修整
fn c<T: Trait1>() -> T {
T::method1()
}

自分を返すmethod1()を持つトレイトTrait1を宣言しておく
trait Trait1 {
fn method1() -> Self;
}

そして型Aに対してそのトレイトを実装すれば動く
impl Trait1 for A {
fn method1() -> Self {
Self { b: 1 }
}
}
もちろんmethod1を引数付きのメソッドにしてもOK

**デフォルトの名無しさん** · 2022/05/29(日) 18:42:28.03

>>377
C++すごいな
なんでエラーにならんのかわからん

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

>>381
Tに依存する箇所のコンパイルを保留してから、実際にT=Aとしてみてインスタンス生成するからね。
https://wandbox.org/permlink/zOH2lP3k2MEPYwsp

conceptで制限はかけられるけど本質は変わらん
https://wandbox.org/permlink/CdKBg61cUgFy2tBs

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

なんだじゃあRustダメじゃん。

**デフォルトの名無しさん** · 2022/05/29(日) 20:03:03.02

そうだよ
ダメだからお前はRust使わないほうがいいよ

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

どう見てもRustの方が安全安心
C++では>>382においてb以外のメンバ変数(フィールド)があっても動作してしまう
つまり初期化されていない部分が残り未定義動作となる

**デフォルトの名無しさん** · 2022/05/29(日) 20:38:31.90

未定義動作ではない。

**デフォルトの名無しさん** · 2022/05/29(日) 20:38:35.33

単一の機関が作ってるなら未定義動作なんて生じないんだけどなｗ

**デフォルトの名無しさん** · 2022/05/29(日) 20:50:06.03

C++では未初期化部分がある時
そこを利用した全体が未定義動作となる

**デフォルトの名無しさん** · 2022/05/29(日) 21:08:46.86

>>382
なるほど
俺の知ってるジェネリックの常識とは違うがある種の合理性はあるな

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

未初期化領域があっても未初期化領域を読み出さなければ未定義動作にはならない
なので後からでも読み出す前にデータを書き込めば合法

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

そもそも初期化されます

https://ja.cppreference.com/w/cpp/language/aggregate_initialization

struct A { int x; int y; int z; };
A a{.y = 2, .x = 1}; // エラー、指示子の順序が宣言の順序と一致しません。
A b{.x = 1, .z = 2}; // OK、 b.y は 0 に初期化されます。

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

>>385
嘘つき。

**デフォルトの名無しさん** · 2022/05/29(日) 23:38:42.10

Rustのジェネリクスは
型Tに対してトレイト境界を増やせば増やすほど型Tを使って様々なことができるようになっていく
今回のように型Tに対してトレイト境界が何も無ければ任意の型に適用できる代わりにできることが非常に少ない

例えばC++とは異なりRustではデフォルト値で初期化することすら指定なしにはできない
Defaultトレイトをトレイト境界に持ち、さらにそのメソッドを用いてT::default()することで、
初めてようやくデフォルト値で初期化されたT型を得ることができる
これにより「ある型にとってデフォルト値とは何か」「そもそもその型にデフォルト値はあるのか」「デフォルト値が使われるのはいつか」
といった諸問題を全て解決している
C++の複雑なルールと異なりRustでは非常に簡単でわかりやすくなっている

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

一方C++erはデフォルトコンストラクタを使ってデフォルト値を定義した

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

長いからデフコンって略したほうが良くないっすか？

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

全てを明瞭シンプルにしたことがRustの勝因

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

なんだじゃあJavaと一緒じゃん。

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

明示的に指示されないメンバも初期化されることに気づけなかったのはC++の仕様が複雑すぎるため
僕が悪いのではないことは明らか

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

Rustは綺麗に整理されてるいるから複雑な個別ルールを覚えなくて済むね

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

トレイトを増やしすぎて普段は必要ない補完候補が気持ち悪いぐらい出てくる破綻言語

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

C#は良い言語ですよ

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

>>400
ほんこれ

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

そんなに補完優秀だったっけ？
rust-analyzer?

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

RustはDと同じ臭いがする

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

言ってることはHaskellと同じだと思います！

・コンパイルを通ればバグがないことが保証される。
・静的に解決するのでCの10倍速い。
・C++は遅い。
・C++は危険。

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

Rust批判は専用スレでどうぞ

Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/

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

>>405
> ・静的に解決するのでCの10倍速い。
意味わからんw

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

Rust屋さんはCを目の敵にしてるから。

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

Rust批判はこのスレでどうぞ

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

Ruby批判もこのスレで良いですか？

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

>>405
haskellでそんなこと聞いたこと無いが。

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

>>410
それはダメ

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

>>369
Pinは1回だけでいい
そしてas_mutしてresumeする
let mut g = Pin::new(&mut generator);
assert_eq!(GeneratorState::Yielded(1), g.as_mut().resume(()));
assert_eq!(GeneratorState::Yielded(2), g.as_mut().resume(()));
assert_eq!(GeneratorState::Yielded(3), g.as_mut().resume(()));
assert_eq!(GeneratorState::Complete("end"), g.as_mut().resume(()));

**デフォルトの名無しさん** · 2022/05/31(火) 00:29:14.66

CLI向けのコマンドラインオプションと設定ファイルと環境変数統一的に扱えるライブラリとかない？
コマンドラインで指定があればそれを、なければ環境変数を、それもなければ設定ファイルを、どれもなければデフォルト値を読む
っていう動作を各オプションについてやってくれるライブラリが欲しい

**デフォルトの名無しさん** · 2022/05/31(火) 00:42:08.60

clap+argfileでいけるかな？

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

大量じゃなければdotenv＋clapで列挙していけばいいね

#[derive(Parser)]
struct Args {
#[clap(long, env = "TEST_NAME", default_value = "デフォルト値")]
test_name: String,
}

dotenv::from_filename("設定ファイル名").ok();
let args = Args::parse();
println!("{}", args.test_name);

argsをparseする前にdotenvで設定ファイルから環境変数へ流し込んでおくと
CLI引数→環境変数→設定ファイル→デフォルト値の順

**デフォルトの名無しさん** · 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のような他人叩きはやめましょうね