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/27(金) 10:47:17.91

>>358
ターミナルが標準出力に出てきたのを表示するのがボトルネックになってるだろうな
./a.out > /dev/null するか、printlnの代わりにファイル書き込みするのが手っ取り早い

**デフォルトの名無しさん** · 2022/05/27(金) 23:42:23.72

traitでasync fnなメソッドを宣言してはいけない理由を教えてください

**デフォルトの名無しさん** · 2022/05/28(土) 00:48:37.27

https://github.com/rust-lang/rfcs/issues/2739

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

async fnはsyntax sugarだから例えば以下は同じ

async fn delayed_add(a: i32, b: i32) -> i32 {
sleep(Duration::from_secs(5)).await;
a + b
}

fn delayed_add(a: i32, b: i32) -> impl Future<Output = i32> {
async move {
sleep(Duration::from_secs(5)).await;
a + b
}
}

つまり現在のRustコンパイラではまだimpl Traitを使える場所が限定されているというもっと大きな問題のために今は使えない
GATsなど現在進行中の諸問題が解決すればいずれ使えるようになるはず

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

現状の対策方法としてはimpl FutureをdynにしてBox::pinして返す

trait Foo {
fn delayed_add(a: i32, b: i32) -> Pin<Box<dyn Future<Output = i32>>>;
}

impl Foo for () {
fn delayed_add(a: i32, b: i32) -> Pin<Box<dyn Future<Output = i32>>> {
Box::pin(async move {
sleep(Duration::from_secs(5)).await;
a + b
})
}
}

fn main() {
block_on(async {
let x = <() as Foo>::delayed_add(1, 2).await;
println!("x = {x}");
});
}

これでtraitにて非同期関数を使える

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

それを手動で変換するのは面倒かつコードも見にくいので自動変換してくれる#[async_trait]を使えばasync fnと書ける

use async_trait::async_trait;

#[async_trait]
trait Foo {
async fn delayed_add(a: i32, b: i32) -> i32;
}

#[async_trait]
impl Foo for () {
async fn delayed_add(a: i32, b: i32) -> i32 {
sleep(Duration::from_secs(5)).await;
a + b
}
}

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

おじさん調査お疲れ様でした。

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

・塩野義製薬が週休3日制導入へ来年4月、副業も解禁
・塩野義製薬が「週休３日」選択可能に　給与は『週休２日の８割』副業や学び直しを支援
・【フォーカス】サタケ／週休３日制　通年導入めざし夏季のみ試行中　交代制で水曜を休日に
・旅館なのに週休3日!?陣屋・若女将の常識を覆した組織改革
・“時代錯誤”から残業ゼロ、週休3日に！　鳥取の不動産会社が
　レガシー企業からDX先進企業になれたワケ
・ネクスウェイ、週休4日制・1日3時間勤務選択できる勤務体系を導入
・日本初「週休4日制度」で、優秀な人材を採用するしくみとは？ ?
　ナレッジソサエティ久田社長に聞いてみた

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

もう借りまっか

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

ジェネレーターはいつstableになりますか

**デフォルトの名無しさん** · 2022/05/28(土) 23:09:24.03

stableを期待しているということは現状の仕様で納得なんだろうけど
resumeの仕方とか値の受け取り方とか軽快じゃなくね？

let mut generator = || {
yield 1;
yield 2;
yield 3;
return "end"
};
assert_eq!(GeneratorState::Yielded(1), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Yielded(2), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Yielded(3), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Complete("end"), Pin::new(&mut generator).resume(()));

例えばresume構文を用意して記述を見やすくするとか
return値は廃止してOption<T>で返しreturn;でNoneにするとか

**デフォルトの名無しさん** · 2022/05/28(土) 23:30:01.77

個人的にはIteratorがyield使って実装できるようになれば満足なのでGeneratorそのものの型とかはそんなに気にしてなかった

**デフォルトの名無しさん** · 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

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