Rust part12

**デフォルトの名無しさん** · 2021/08/24(火) 22:55:27.78

公式
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のasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

前スレ
Rust part11
https://mevius.5ch.net/test/read.cgi/tech/1623857052/

**デフォルトの名無しさん** · 2021/08/28(土) 11:48:49.70

>>145
MISRAに従ってコーディングするの辛いぞ。

**デフォルトの名無しさん** · 2021/08/28(土) 12:14:36.47

>>160
特撮にはCG有るぞ

**デフォルトの名無しさん** · 2021/08/28(土) 12:24:36.28

次のようなloop文のプログラム(可動)を
while文やfor文に書き換えてわかりやすくしたいのですが
上手く値をbreakできないので助けてください

fn main() {
　let a = [3, 5, 1, 6, 9, 4];
　print_first_even_else_zero(&a);
}
fn print_first_even_else_zero(a: &[i32]) {
　let mut i = a.iter();
　let even = loop {
　　if let Some(&n) = i.next() {
　　　if n % 2 == 0 {
　　　　break n;
　　　}
　　} else {
　　　break 0; // not found
　　}
　};
　println!("{}", even);
}

例えばwhile文なら　let even = while let Some(&n) = i.next() { となりそうで
さらに可能ならfor文で　let even = for &n in a { となるかと思うのですが

**デフォルトの名無しさん** · 2021/08/28(土) 12:44:34.41

let even = a.iter().find(|n| *n % 2 == 0).unwrap_or(&0);

**デフォルトの名無しさん** · 2021/08/28(土) 13:03:12.27

>>164
当然それはわかりますが、for式やwhile式ではどうなるのか、という質問です

**デフォルトの名無しさん** · 2021/08/28(土) 13:07:44.67

前スレより

625 デフォルトの名無しさん 2021/08/16(月) 09:44:36.63 ID:MZWGbmHz
loop式はbreakで指定した値を返せるのに
なぜwhile式やfor式は値を返せないの？
Option型にしてbreakで値を指定した時だけSome(値)としてそれ以外はNoneとすれば便利なのに

630 デフォルトの名無しさん sage 2021/08/16(月) 14:32:54.40 ID:ebJKRLr3
手間かけて機能拡張するほどのメリットがないってことだろうね
https://github.com/rust-lang/rfcs/issues/1767#issuecomment-292678002

**デフォルトの名無しさん** · 2021/08/28(土) 13:08:21.57

そうでしたかすみません
forとwhileは値を返さないのでご想像のようにはなりません

**デフォルトの名無しさん** · 2021/08/28(土) 14:07:01.17

>>166
なるほど
そこでの議論を読むと一番の肝が、
「for式が()を返さないと、最後がfor式で終わる関数の返り値で互換性が無くなる」
というところにあるようですが
「break;」が()を返すことにすれば特に問題ないように見えます
実際にloop式で値なしのbreakだと()を返しています

つまり
・「for/while/loop式が返す型」は「break式の型」とする
・「値指定のない『break;』の型」は()とする
・「break式がない場合の型」も()とする
ここまでは現状と同じになりますね

問題はfor/while式はbreakせずともループを抜けるので、値を返すには、
・「『break 値;』があるfor/while式」は「else節を取ってbreak式と同じ型を返す」
という単純ルールだけで済むように見えます
何か見落としがあるでしょうか？

**デフォルトの名無しさん** · 2021/08/28(土) 14:41:22.43

8日前にちょうどその内容で開かれたRFCあるじゃん
イテレータで思考停止してたわ
https://github.com/rust-lang/rfcs/pull/3163

**デフォルトの名無しさん** · 2021/08/28(土) 15:14:25.46

>>169
なるほどありがとうございます

ところで現状のRustで>>163の例のloop式をfor式で行おうとすると
即時関数を使ってbreakをreturnに置き換えることで
let even = (|| {
　for &n in a {
　　if n % 2 == 0 {
　　　return n;
　　}
　}
　0
})();
と実現できることを思いつきましたが
この方法は表記コストはともかく実行コストもかかってしまいますか？

ちなみにこの「最初の偶数を見つけるコード」はあくまでも例として単純化したものを出しているだけで
実際には様々な例でこのパターン(＝forやwhileで値を返せると便利)が出てくるので簡略な例題として話をしています

**デフォルトの名無しさん** · 2021/08/28(土) 15:30:38.48

>>168
イテレータのコードのほうが遥かにわかりやすい上に簡潔なので
新しく文法を拡張する価値がないと開発陣は考えてる点を見落としてる。る？
特にPythonの失敗例を鑑みれば機能追加される可能性は限りなくゼロ

**デフォルトの名無しさん** · 2021/08/28(土) 15:43:20.61

>>171
現実にはfindより複雑なことでも使うだろうし
async関数呼び出して判断もあるだろうし
イテレータでは無理なことも多いのでは？

**デフォルトの名無しさん** · 2021/08/28(土) 16:01:24.35

Rustに限った話じゃないけど新しめの言語だとイテレータで記述可能な
ループは、出来るだけイテレータで記述するのが主流じゃね
forだのwhileはループ条件の誤りから簡単にバグが生まれるし
使わないで済むならそれに越したことはない
CやCの派生系言語がメインの人には理解しがたいかもしれないが

**デフォルトの名無しさん** · 2021/08/28(土) 16:07:59.88

C++ だとテンプレートの組み合わせで回すのも一般的だけど
Go だと凝ったことするよりなんでも愚直にループを回したほうがいいというのは
基本的なスタンスになってるよね。

**デフォルトの名無しさん** · 2021/08/28(土) 16:18:39.14

>>172
説得力のある実例を出せば今みたいにRFCが即closeされることはないんじゃない？

状況によってはイテレータを拡張したほうがいいという判断も有り得るし
今のforやwhileループみたいにmutで定義した変数を更新するのでも十分かもしれない

**デフォルトの名無しさん** · 2021/08/28(土) 17:39:28.92

>>173
なるほど
出来るだけイテレータで記述する質問です
コマンドライン引数の数字の和をイテレータでpanicさせずに求める場合
これよりもっと短く出来ないでしょうか？
fn main() -> Result<(), std::num::ParseIntError> {
　println!("Sum: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).collect::<Result<Vec<i32>,_>>()?.iter().sum::<i32>());
　Ok(())
}
以下のように正しく実行できているのですがコードが長いのが気になっています
$ cargo run 10 20 30 40 50
Sum: 150
$ cargo run 10 20 XX 40 50
Error: ParseIntError { kind: InvalidDigit }

**デフォルトの名無しさん** · 2021/08/28(土) 17:58:47.12

そんなに長い？

**デフォルトの名無しさん** · 2021/08/28(土) 18:59:50.15

twitterで「Rust過激派がルール違反と判断された」
「CやC++のこと書いてた人にRustの話吹っかけて迷惑かけてた怖い人たち」
という話を見たが、誰の事？
どういうことなんだ？

**デフォルトの名無しさん** · 2021/08/28(土) 19:21:11.03

>>178
c++テンプレートテクニックの著者のことか？

**デフォルトの名無しさん** · 2021/08/28(土) 19:24:41.12

>>61
int* p1 = malloc(sizeof(int));
int* p2 = malloc(sizeof(int));
int* p3;
if (なんかの条件) p3 = p1; else p3 = p2;
free(p1);
p1 = NULL;
if (なんかの条件) p3 = NULL;
// p2はまだまだ使う
こうすればいいだけの話だろ？ガイジか？
このコードの後 p2またはp3どちらかをfreeしても二重開放にならんよ
このぐらいも考えられないのかガイジは(笑)

**デフォルトの名無しさん** · 2021/08/28(土) 19:28:28.84

いちいち差別的な用語を使わないとレスもできないのか
プログラマとしては一流なのかもしれないが、人間としては最低だな

**デフォルトの名無しさん** · 2021/08/28(土) 20:41:09.02

>>177
このcollectしてから再びiterするところを何とか出来ないものかなと
println!("Sum: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).collect::<Result<Vec<i32>,_>>()?.iter().sum::<i32>());
イテレータだけを使う限界？

同じことをfor文を使うと短くなってわかりやすくなります
let mut total = 0;
for s in std::env::args().skip(1) {
　total += s.parse::<i32>()?;
}
println!("Sum: {}", total);

**デフォルトの名無しさん** · 2021/08/28(土) 21:00:48.99

std::env::args().skip(1).map(|s| s.parse::<i32>()).sum::<Result<i32, _>>()?

**デフォルトの名無しさん** · 2021/08/28(土) 21:02:35.90

ParseIntError返しても処理しないんだから
unwrap_or(0)みたいなので十分じゃないの？

fn main() {
let args = std::env::args().skip(1);
let sum: i32 = args.map(|s| s.parse().unwrap_or(0)).sum();
println!("Sum: {}", sum);
}

入力、計算、出力で分けてる

**デフォルトの名無しさん** · 2021/08/28(土) 21:14:51.79

>>184
非整数は飛ばす仕様になってる
エラーはエラーだと示すべきかな
あとエラー処理コードがないのは質問の本質じゃないからかと

**デフォルトの名無しさん** · 2021/08/28(土) 21:23:19.42

println!("{}", std::env::args().skip().try_fold(|sum, s| Ok(sum + s.parse::<i32>()?))?);

try_fold使うと?演算子の入る場所が変わらずに済むっぽいな

**デフォルトの名無しさん** · 2021/08/28(土) 21:24:03.32

>>183
なるほど!
sum()もcollect()のように様々な形の集積方法が指定できるのですね
i32整数一覧が入力に来るのにsum::<i32>()とi32型指定をしないと怒られた理由がようやくわかりました
sumとcollect以外にもそういう仕様のメソッドはありますか？

**デフォルトの名無しさん** · 2021/08/28(土) 21:34:12.61

いちいち固有のiterator使うとか可読性悪くなるだけって場合も多い

**デフォルトの名無しさん** · 2021/08/28(土) 21:54:20.22

>>186
素晴らしい!
少し修正して以下で上手く行きました
std::env::args().skip(1).try_fold(0, |sum, s| Ok(sum + s.parse::<i32>()?))?
fold()は知っていたのですがtry_fold()でOptionやResultの形でfold()できるとは便利ですね

ここまでまとめると
sum計算はResult型を返せるsum()があるので>>183でも行けて
このtry_fold()ならばsum計算以外にも汎用的に使えますね

**デフォルトの名無しさん** · 2021/08/28(土) 22:01:27.46

>>185
エラーだと示したいなら結果をハンドリングすればいいんじゃないの？

type Result<T> = std::result::Result<T, std::num::ParseIntError>;

fn main() {
let args = std::env::args().skip(1);
let sum: Result<i32> = args.map(|s| s.parse::<i32>()).sum();
match sum {
Ok(sum) => println!("Sum: {}", sum),
Err(e) => println!("Error: {}", e),
};
}

引数ゼロ個とかエラーは1種類じゃまかなえない
ハンドリングしたいならエラー設計がもう少し必要になるだろうね

**デフォルトの名無しさん** · 2021/08/28(土) 22:12:53.29

>>190
もちろんそんなことは皆わかっていて、最後のResultのErr処理は枝葉末節だから略して議論してるのだと思う
あとmain()でResult返してErrなら勝手にエラー表示してくれるみたいで便利
で、>>185で指摘したことは、>>184のunwrap_or(0)使用はエラーが消えるからマズいよね、ということでした

**デフォルトの名無しさん** · 2021/08/28(土) 22:34:29.66

>>191
何をそんなにカリカリしてるんだ？
main()でResult返したいなら別にそれでもいいんじゃない？

fn main() -> Result<()> {
let args = std::env::args().skip(1);
let sum: Result<i32> = args.map(|s| s.parse::<i32>()).sum();
println!("{}", sum?);
Ok(())
}

**デフォルトの名無しさん** · 2021/08/28(土) 22:53:59.26

>>192
皆がわかりきったことしか書いていなくて何をしたいのかわからないけど
Resultはエラー型も示さないとそのコードでは動かないよ

**デフォルトの名無しさん** · 2021/08/28(土) 23:36:35.98

今回はargs部分も枝葉末節なので外してまとめ直すと
『数値と思われる文字列の配列が与えられた時に非数値があればエラーを返すとして』
let a = ["1", "3", "5", "7", "9"];
和の場合はmap()でResultのままsum()に渡してResultを返せる
let sum = a.iter().map(|s| s.parse::<i32>()).sum::<Result<i32, _>>()?;
和だけでなく積などもtry_fold()を使えばResultを返せる
let sum = a.iter().try_fold(0, |sum, s| Ok(sum + s.parse::<i32>()?))?;
let mul = a.iter().try_fold(1, |mul, s| Ok(mul * s.parse::<i32>()?))?;
今回はparse()で文字列→数値のResultだけど一般的にResultを返す関数なら応用可能
皆さんありがとうございました

**デフォルトの名無しさん** · 2021/08/29(日) 09:06:24.35

>>179
指摘している人も、加害者もエピステーメー氏とは全く関係ない人だと思う。

**デフォルトの名無しさん** · 2021/08/29(日) 12:05:26.47

>>195
えぴすめーてーじゃないほうの共著者のほうでしょ

**デフォルトの名無しさん** · 2021/08/29(日) 13:31:13.01

ローマ字で takaha... の人のことか。
Ukic...の人も何か言ってるんだけどどういう相関関係なのか。。

**デフォルトの名無しさん** · 2021/08/29(日) 17:50:42.33

対立煽りに乗らないように

**デフォルトの名無しさん** · 2021/08/29(日) 20:28:38.19

>>174
Goは確かにその方針だけど、イテレータというか高階関数を受ける型が総称では無いから.collectや.mapなんて
型ごとに定義しないと使えないから。Go2になってくれば違ってくると思う
一方でPythonだとfunctools.reduceなんかより、リスト内包表記が使われるのは局所性で速度が速いからだけど
ループで書かずにかなり長い表現をこれで書かれると保守しずらい。
Rustでもイテレータを何回も取り出してcollectしたり、foldしたりをドットで繋げられるのはあまり読み易いとは
言えないと思う。普通にiter()を何度も呼ぶのなら、let it = a.iter();して欲しい

**デフォルトの名無しさん** · 2021/08/29(日) 21:26:36.38

そのitは一度しか使えないのでわ

**デフォルトの名無しさん** · 2021/08/29(日) 21:37:15.37

collect()したやつに.iter()は確かにやめてほしい
終端操作するなら何か変数に入れた上でやってほしい

**デフォルトの名無しさん** · 2021/08/29(日) 21:56:31.67

AdapterとConsumerは必ず分けろってこと？
もちろん分けたほうがいい場合もあるだろうけど
別に一緒でもいいと思うんだけどな

**デフォルトの名無しさん** · 2021/08/29(日) 22:06:52.56

>>201
中間変数を使うか否かだけの問題だからどうでもいい話
言語自体やその利用方法に本質的な問題があるわけではない

一方で>>199のGoの問題は深刻
Rustがトレイトで解決している分野だ

**デフォルトの名無しさん** · 2021/08/29(日) 22:08:51.10

上にあるコードでcollect()した後にiter()してるやつのことか
それなら分かる

**デフォルトの名無しさん** · 2021/08/29(日) 22:19:15.00

あぁそういうこと
俺は別に繋がってていいかな

**デフォルトの名無しさん** · 2021/08/29(日) 22:49:50.89

>>204
それコードを改善したいという相談やんけ
しかも最終的には>>194のコードへと短くわかりやすくなったのだからRustはよく考えられてるなあとしか

**デフォルトの名無しさん** · 2021/08/29(日) 23:12:51.30

>>206
だからこそcollect()した後にiter()してるコードは改善したほうがいいよって話だろ？

**デフォルトの名無しさん** · 2021/08/29(日) 23:54:47.37

和も積も求めたい時はどうすればいいかな?
文字列から数値への変換を二度するのを避けるとして
一つの方法はこのように一旦collectとして数値のVecを作ってしまう
fn main() -> Result<(), std::num::ParseIntError> {
　let input_numbers: Vec<i32> = std::env::args().skip(1).map(|s| s.parse::<i32>()).collect::<Result<_,_>>()?;
　println!("和: {}", input_numbers.iter().sum::<i32>());
　println!("積: {}", input_numbers.iter().fold(1, |mul, n| mul * n));
　Ok(())
}
それともcollectせずにイテレータのままで止めておいて使う?

**デフォルトの名無しさん** · 2021/08/29(日) 23:59:56.40

質問者とイライラ君が同一人物のパターン?

**デフォルトの名無しさん** · 2021/08/30(月) 00:06:07.90

product()使わないの？

**デフォルトの名無しさん** · 2021/08/30(月) 00:06:33.11

>>208
foldで和と差の2要素のタプルをとりまわせば良いだけ

**デフォルトの名無しさん** · 2021/08/30(月) 00:56:00.83

こうかな
println!("和: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).sum::<Result<i32,_>>()?);
println!("積: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).product::<Result<i32,_>>()?);
println!("(和,積): {:?}", std::env::args().skip(1).try_fold((0, 1), |(sum, mul), s| { let n = s.parse::<i32>()?; Ok((sum + n, mul * n))})?);

**デフォルトの名無しさん** · 2021/08/30(月) 01:17:16.84

>>209
っぽい

**デフォルトの名無しさん** · 2021/08/30(月) 01:45:40.23

C++君も

**デフォルトの名無しさん** · 2021/08/30(月) 05:11:39.37

この前はNim連呼してた

**デフォルトの名無しさん** · 2021/08/30(月) 05:23:26.66

二重解放NULL荒らしもな

**デフォルトの名無しさん** · 2021/08/30(月) 08:14:19.28

>>209
確かにこんな特徴的な勘違いをするやつが同時に二人出現するわけないわな

**デフォルトの名無しさん** · 2021/08/30(月) 08:46:37.85

じゃあワイはガリガリ君で

**デフォルトの名無しさん** · 2021/08/30(月) 09:38:42.61

>>214
C++ vs Rustスレでやれと何度言っても聞かずにここでイライラしてるよな

**デフォルトの名無しさん** · 2021/08/30(月) 10:38:26.28

上のイテレータ関連の質問に便乗ですが、
二次元vecの各要素をv[i][j]としたときに、
jごとの総和を計算するやつをイテレータできれいに書く方法ありますか？

例えばこういうやつです

let v = vec![vec![0; n]; m];
// (vの各要素を設定）
let mut result = vec![0; n];
for i in 0..m {
for j in 0..n {
result[j] += v[i][j];
}
}

**デフォルトの名無しさん** · 2021/08/30(月) 10:46:23.34

>中間変数を使うか否かだけの問題だからどうでもいい話

Rustの場合、ライフタイムとオーナーシップの関係で
中間変数を使うか否かは結構重要な問題だったりする

**デフォルトの名無しさん** · 2021/08/30(月) 10:56:01.57

>>220
mapしてsumすればいいだけでは？
きれいかどうかは知らんけど

**デフォルトの名無しさん** · 2021/08/30(月) 12:15:23.57

>>212
これ競プロ用でしょ
一般的なプログラミングとは観点が違うから最初に競プロ用だと書いておいたほうがいいぞ

**デフォルトの名無しさん** · 2021/08/30(月) 12:35:22.36

>>222
mapとsumで書けます？
iごとの総和なら単純に
v.into_iter().map(|v| v.into_iter().sum()).collect()
みたいな感じでいけるとおもうのですが、jごとだとちょっとわからないです

>>223
そうですね（実はもともとの発端は競プロではなかったりするのですが

**デフォルトの名無しさん** · 2021/08/30(月) 13:18:46.38

(0..n).map(|j| (0..m).map(|i| v[i][j]).sum()).collect()

2重forをの親子を逆転してイテレータメソッドチェーンに変換しただけという感じ
こんなことよりもっと意味のあることに頭使ったほうがいい
イテレータでとあったから上を書いたが現実にはndarray入れてsum_axis使うのがいいだろう
https://docs.rs/ndarray/0.15.3/ndarray/struct.ArrayBase.html#method.sum_axis

**デフォルトの名無しさん** · 2021/08/30(月) 13:30:16.69

こんなかんじかな

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=e302c841c8dd709418f923ea1ad07868

**デフォルトの名無しさん** · 2021/08/30(月) 13:33:43.06

ほぼかぶってたごめん

**デフォルトの名無しさん** · 2021/08/30(月) 13:38:15.69

>>225-226 インデックス自体のイテレータを作るって発想がありませんでした、ありがとうございます
競プロ用ではないしndarray使うのも考えてみます

**デフォルトの名無しさん** · 2021/08/30(月) 14:45:34.31

汎用的には縦横入れ替えのtransposeを作っておけば色んな操作が楽かもね
イテレータ作成はサボってとりあえず関数版
fn transpose<T>(v: &Vec<Vec<T>>) -> Vec<Vec<T>> where T: Copy {
　(0..v[0].len()).map(|j| v.into_iter().map(|vv| (*vv)[j]).collect::<Vec<T>>()).collect()
}
fn main() {
　let v = vec![vec![1,2,3], vec![4,5,6], vec![7,8,9], vec![10,11,12]];
　let w = transpose(&v);
　println!("{:?}", v); // [[1, 2, 3], [4, 5, 6], [7, 8, 9], [10, 11, 12]]
　println!("{:?}", w); // [[1, 4, 7, 10], [2, 5, 8, 11], [3, 6, 9, 12]]
}

**デフォルトの名無しさん** · 2021/08/30(月) 20:06:03.21

transposeみたいな関数用意すべきかは配列の要素数次第かなあ
たかだか1度しか読まないデータのためだけに配列全体をコピーするのはもったいないケースはありそう

**デフォルトの名無しさん** · 2021/08/30(月) 20:10:57.31

性能気にするなら Vec<Vec<_>> の形で数値格納するのではなく
Vec<_> に格納して (i, j) -> j*n+i みたいにインデックスを変換してくれるラッパーを被せた方がよさそう

**デフォルトの名無しさん** · 2021/08/30(月) 20:40:55.84

>>231
それがndarrayなのでは?

**デフォルトの名無しさん** · 2021/08/30(月) 20:50:30.90

これ匙投げたな
https://lkml.org/lkml/2021/7/4/171

**デフォルトの名無しさん** · 2021/08/30(月) 21:09:01.34

C++ドロップアウターの吹き溜まりスレ

**デフォルトの名無しさん** · 2021/08/30(月) 21:16:46.70

>>223
競プロではむしろ回答時間や処理速度のほうが重要なので、
あえてこういうのをイテレータで実装しようとしないよ
おれなら間違いなくforで回す。わざわざイテレータで回そうと考える時間が無駄

だけど、後から振り返って、これをイテレータで1行で簡単に表示できるんじゃないかな？と思うことはよくあるんよ。
そして、ドキュメントを見返したり、他人のソースを見て、ああこういうやり方もあるんだなと学習する

競プロは実際のコーディングに役立たないという人もいるけど、
普段、自分が利用しないメソッドや方法を発見すること、実務で役立ちそうなアルゴリズムがあることを知る
という意味では意味があると思う

**デフォルトの名無しさん** · 2021/08/30(月) 21:24:57.91

>>235
競プロに対する君の考えを急に述べられましても・・・
誰も興味ないよ

**デフォルトの名無しさん** · 2021/08/31(火) 00:14:29.47

>>236
逆にいうと、君が競プロはこういうものだろうという勝手な解釈で意見を言うことにも意味がないということよ
それこそ誰も興味がない

**デフォルトの名無しさん** · 2021/08/31(火) 01:03:24.14

今日もまたこのパターンw
ヤバいやつっすね

**デフォルトの名無しさん** · 2021/08/31(火) 01:24:07.51

たまにLKMLのURL貼られるけどURLだけ貼られてもなんもわからん

**デフォルトの名無しさん** · 2021/08/31(火) 09:11:07.02

>>235
最適化まで考えるならforなんだろうけど、iterやcollectなんかが最適化が効かないのは今昔で、いずれは
最適化されるんじゃないだろうかと希望的観測を述べてみたり。実際gccなんかだとリンク時の最適化なんて
オプションあるし、あんまり凝ったiter/map/collect/foldだと理解に時間が掛かることはいなめない

**デフォルトの名無しさん** · 2021/08/31(火) 09:16:05.39

ぼくのかんがえた最強のコードが見下されたと思って悔しかったんだろうな
図星だったからこそ競プロでは逆にこんな書き方しないとか競プロは役に立つとか自己正当化に必死になる

追い越されたらバカにされたと思って煽り運転をする人と心理と同じなのでどちらの側も少し気を付けたほうがいい

**デフォルトの名無しさん** · 2021/08/31(火) 10:02:54.76

forよりイテレータのメソッドチェーンのほうが処理速度速かった気がするんだが

**デフォルトの名無しさん** · 2021/08/31(火) 10:51:36.61

やっていることが同じなら (最適化などによって) 結果のコードもおおよそ同じところに着地するよ。

**デフォルトの名無しさん** · 2021/08/31(火) 12:44:14.75

C/C++でポインタを使うと速い(プラシーボ)

**デフォルトの名無しさん** · 2021/08/31(火) 13:28:16.71

せやな。素朴なコンパイラならともかく
いまどきの最適化能力を期待できるなら
ポインタはエイリアス解析を困難にするから
むしろ足を引っ張る要素になる。

**デフォルトの名無しさん** · 2021/08/31(火) 14:25:42.76

>>244
ポインタは適切に使えばデータ構造やアルゴリズム自体が根本的に変えることが
できるので使わない時と比べて計算オーダー自体が劇的に変化することがあり、
プラシーボではない。
Rustはその点でC/C++に勝てない事がある。

**デフォルトの名無しさん** · 2021/08/31(火) 14:28:10.16

例えば、動的配列であるところのVectorはポインタでアクセスしても余り
効率は良くならないが、LinkedListは構造的にポインタで連結されており、
首尾一貫して添え字アクセスを使わずに必ずポインタでノードを識別する
ようにすれば、Vectorに比べて劇的に効率アップできることがある。
それはRustではほぼ不可能。ベンチマークはこの点が反映されてない。

**デフォルトの名無しさん** · 2021/08/31(火) 15:24:34.70

続きはこちらで
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**デフォルトの名無しさん** · 2021/08/31(火) 21:08:01.25

>>240
最適化ではなくて、forを利用してindexで回さないとできないことが山ほどあるんだよね
例えば、二分探索や三分探索とか

foreach（a in vec）で順繰りに回せる処理ならいいけど、
そういう処理ではできないこともあるので、
forで回す前提で考えたほうが、あとから修正する余地があるので、どうしてもforでindexで回すことになる
これは、イテレータのほうがループが速いというのと、また別の問題

**デフォルトの名無しさん** · 2021/08/31(火) 21:25:16.59

rustのforは他言語でいうforeach(a in vec)やろ

**デフォルトの名無しさん** · 2021/08/31(火) 21:26:56.02

そもそも二分探索を普通forで実装しないだろ

**デフォルトの名無しさん** · 2021/08/31(火) 21:39:55.47

for each 的なループで書いたものを二分探索に直す時点でプログラムとしては別物になりそうなんだけど
元のコードを iter じゃなく index アクセスするコードにしておくことでこの書き換えがどれほど楽になるのかね

まあここまでくると個人の好みの話なのでお好きにどうぞとしか言えないが

**デフォルトの名無しさん** · 2021/08/31(火) 21:59:30.62

Rustのfor式を理解してなかったんかーいっ！！！

**デフォルトの名無しさん** · 2021/08/31(火) 22:43:09.54

>>250
それは違う

まず1点目
リスト対するfor文をforeachと書かずforと書く言語の方が非常に多く一般的
C++もJavaもJavaScriptもPythonもRubyもAwkもshもリストに対してfor文

次に2点目
Rustのfor文はIterator loopと明確に書かれてるようにリストや配列に対してではなくイテレータ正確にはIntoIteratorを実装するものに対して

**デフォルトの名無しさん** · 2021/08/31(火) 23:30:53.76

もうコイツどうにかしてくれwww

**デフォルトの名無しさん** · 2021/08/31(火) 23:44:40.84

>>254
恥かいたので頑張って調べましたってレスなんだろうけど何一つ理解できてないぞ
もう一回調べ直してこい

**デフォルトの名無しさん** · 2021/08/31(火) 23:52:15.67

調べたのにfor式を理解できんかったんかーいっ！！！

**デフォルトの名無しさん** · 2021/08/31(火) 23:54:52.53

Rustのforで二分探索ってどうやるのか気になる

**デフォルトの名無しさん** · 2021/08/31(火) 23:56:09.61

どうせ自分で二分探索なんか実装しないだろ
気にするな
標準ライブラリ使え

**デフォルトの名無しさん** · 2021/09/01(水) 01:38:57.54

>>258
for _ in 0..log2(n) as usize 的に回せばいいんでは?

まずやらないけど

**デフォルトの名無しさん** · 2021/09/01(水) 01:59:11.36

>>260 それでどうやるかわかんねーんすけど
少なくとも>>249が言ってるforでindex回すってのとは違うような