Qiita 7 - キータぞ、来たぞ、キータだぞー (292ﾚｽ)
Qiita 7 - キータぞ、来たぞ、キータだぞー http://mevius.5ch.net/test/read.cgi/tech/1757733847/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
40: デフォルトの名無しさん [sage] 2025/09/17(水) 09:21:49.27 ID:0mQm0ojt >>38 再帰を使わないシンプルな版を書いて主張すれば良い http://mevius.5ch.net/test/read.cgi/tech/1757733847/40
41: デフォルトの名無しさん [sage] 2025/09/17(水) 09:26:43.33 ID:MzfCTW9l >>9 arr[n - i - 1]が不格好ではあるな http://mevius.5ch.net/test/read.cgi/tech/1757733847/41
42: デフォルトの名無しさん [sage] 2025/09/17(水) 10:55:53.14 ID:0mQm0ojt >>41 func ReverseArray(arr []int) []int { n := len(arr) result := make([]int, n) for i, j := 0, n - 1; i < n; i, j = i + 1, j - 1 { result[i] = arr[j] } return result } http://mevius.5ch.net/test/read.cgi/tech/1757733847/42
43: デフォルトの名無しさん [sage] 2025/09/17(水) 21:20:35.77 ID:0mQm0ojt しまったー！ ElixirChip初お目見え会今日だったじゃーん 忘れてたわー！ざーんねーん！ とか言ったりして。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/43
44: デフォルトの名無しさん [sage] 2025/09/17(水) 22:01:15.40 ID:+QFNSyi5 配列などの各要素を巡る抽象化はイテレータだよ 抽象化の役割分担がわかりやすいRustで説明すると 今回の各要素の順番を逆順にしたベクタを作る関数はこうなる fn reverse_value<T: Clone>(input: &[T]) -> Vec<T> { input .iter() // 各要素への参照を巡るイテレータ .rev() // それを逆順に巡る .cloned() // 各要素への参照から値を複製して値を得る .collect() // それらの値を今回は返り型で指定のVecへ収集 } このイテレータは各要素への参照(ポインタ)を動かしていくので 今回のように値を複製したい場合は.cloned()が必要となる それを無しにすると以下のように各要素への参照のベクタが得られる fn reverse_reference<T>(input: &[T]) -> Vec<&T> { input .iter() // 各要素への参照を巡るイテレータ .rev() // それを逆順に巡る .collect() // それらの参照を今回は返り型で指定のVecへ収集 } このように抽象化された各パーツを組み合わせることで 可読性と安全性と高速実行を両立させている http://mevius.5ch.net/test/read.cgi/tech/1757733847/44
45: デフォルトの名無しさん [sage] 2025/09/17(水) 22:14:21.95 ID:Iu+PtAN6 改行CRとLFの真実：MS-DOS・BIOS・WIN10での挙動比較 https://qiita.com/earthen94/items/9c1a1fb8e1c7a2f32432 > Windows10 > '\r'で行頭に戻ることは確認できましたが、'\n'では下の行に下がるだけでなく行頭に自動的に戻されてしまうようです。 '\n'で行頭に移動するのはC言語の仕様で「\n 改行（new line）現表示位置を次の行の最初の位置に移動する。」となってるからで、WindowsではユニバーサルCランタイム (UCRT)が標準出力をテキストモードでオープンしてるため '\n' が '\r' + '\n' に変換されるからで、さらに最近の Windows Terminal は '\n' の動作が行頭に移動するようなってるので、とか説明せんといかんのかな、メンドい。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/45
46: デフォルトの名無しさん [sage] 2025/09/17(水) 22:54:27.39 ID:Iu+PtAN6 せっかくなので>>44の関数のベンチマークをしてみた。 https://godbolt.org/z/KxYEdofWd reverse_value() のほうがちょっと速いのかな。 Rustって知らんけどblack_boxなんてあんのは面白いな。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/46
47: デフォルトの名無しさん [sage] 2025/09/17(水) 23:13:57.67 ID:2et8KGNs >>46 参照型つまりアドレスたぶん64bitを収容と i32型つまり32bitを収容のサイズの異なる比較になってしまってないかね？ http://mevius.5ch.net/test/read.cgi/tech/1757733847/47
48: デフォルトの名無しさん [sage] 2025/09/18(木) 00:40:20.60 ID:sD2s9VAq for でぐるぐる回すとこんな感じかな。 fn reverse_array<T: Clone>(input: &[T]) -> Vec<T> { let mut result = Vec::with_capacity(input.len()); for i in (0..input.len()).rev() { result.push(input[i].clone()); } result } https://godbolt.org/z/5dc1KaWsd http://mevius.5ch.net/test/read.cgi/tech/1757733847/48
49: デフォルトの名無しさん [sage] 2025/09/18(木) 01:41:40.32 ID:sD2s9VAq 出力の関数名間違ってたので訂正 https://godbolt.org/z/Kb7b3hc6P http://mevius.5ch.net/test/read.cgi/tech/1757733847/49
50: デフォルトの名無しさん [sage] 2025/09/18(木) 16:56:30.82 ID:E/kzpuoF >>44 元のGoのコードがintの配列扱ってるのにジェネリック化してCloneで効率下げてるのなんで?? http://mevius.5ch.net/test/read.cgi/tech/1757733847/50
51: デフォルトの名無しさん [sage] 2025/09/18(木) 17:45:09.89 ID:530bwAJW >>50 Rustのジェネリックは効率を下げなくて従来の型指定した時と全く同じように動作することが特徴です RustのCloneとは参照先から値を複製することです 例えば32bit数値の場合ならばCPUによるメモリ/レジスタ⇔メモリ/レジスタ間のロードやセーブが複製であって必ず行われることなので効率が下がることはありません http://mevius.5ch.net/test/read.cgi/tech/1757733847/51
52: デフォルトの名無しさん [sage] 2025/09/18(木) 23:44:30.13 ID:aCgogNys Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね 安全性などはついでのオマケ http://mevius.5ch.net/test/read.cgi/tech/1757733847/52
53: デフォルトの名無しさん [sage] 2025/09/21(日) 18:14:05.85 ID:MlvLaXh2 再帰派、息してる? http://mevius.5ch.net/test/read.cgi/tech/1757733847/53
54: デフォルトの名無しさん [] 2025/09/21(日) 19:59:36.62 ID:kxRRh56H もれちんは再吃不能 http://mevius.5ch.net/test/read.cgi/tech/1757733847/54
55: デフォルトの名無しさん [sage] 2025/09/21(日) 19:59:57.80 ID:hyRHfdTv 天才すぎて再起不能 http://mevius.5ch.net/test/read.cgi/tech/1757733847/55
56: デフォルトの名無しさん [] 2025/09/21(日) 23:24:29.32 ID:wsaoMzy7 >>52 Rustは冗長なくせに変な略語や記号を多用するから可読性は低いよ。JavaとPerlの悪い所取り。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/56
57: デフォルトの名無しさん [sage] 2025/09/21(日) 23:46:21.39 ID:xj5a3FOL >>56 変な記号？ 記号は他の言語と同じ Rustはコードの抽象化に成功していて可読性も保守性も高い http://mevius.5ch.net/test/read.cgi/tech/1757733847/57
58: デフォルトの名無しさん [sage] 2025/09/22(月) 07:39:29.97 ID:2d/wDxg8 Rustの..と..=の違いはセンスないなあと思った。Rubyの..と...も同様。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/58
59: デフォルトの名無しさん [sage] 2025/09/22(月) 08:00:31.81 ID:01ZECo7h >>58 長さlenの連続体(スライス)のインデックスは0からlen-1になるのだから 0..lenが0以上len未満つまり0からlen-1を示すRustの仕様はセンスが良い これを一般的には半開区間と言い数学では[start, end)と表記しstartは含むがendは含まず利点が多い プログラミングでn個を処理するときにインデックスなどを i = 0 から i < n と書くがこれも半開区間でRustなら0..nの表記になる ごく稀にn+1個の処理をする i = 0 から i <= n を扱いたい時には対応する0..=nの表記ができる したがってRustの表記法がベストであることがよくわかる http://mevius.5ch.net/test/read.cgi/tech/1757733847/59
60: デフォルトの名無しさん [sage] 2025/09/22(月) 09:09:30.72 ID:2d/wDxg8 『Rust で書いたプログラムがなんか遅い』 Rustで..=を気軽にホイホイ使ってしまって「なんか遅い」と言ってる例。 抽象化の高い言語を使って何が起きてるか分かってないのも考えものだな。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/60
61: デフォルトの名無しさん [sage] 2025/09/22(月) 09:16:25.38 ID:Ow6is+fL Rubyの .. はPascal と記法を合わせたもので、 ... は番兵を1つ外側に立たせておくくらいのイメージかな。 Rustの .. は、Pascac と記法を合わせることには拘らず、多用される番兵方式を少ない記号数で記述できる方が合理的という判断なんだろう。..= という記法のセンスの良し悪しは何とも言えないが。 どちらも内在的にはそれなりに合理的なんじゃないかな。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/61
62: デフォルトの名無しさん [sage] 2025/09/22(月) 09:59:26.76 ID:ytnqyum6 Pascal方式は1発進と相性がよく1..nがn個になる Rust方式は0発進と相性がよく0..nがn個になる indexが0発進になる言語はRust方式が便利 http://mevius.5ch.net/test/read.cgi/tech/1757733847/62
63: デフォルトの名無しさん [sage] 2025/09/22(月) 10:11:48.70 ID:2d/wDxg8 Pascalは..もforも閉区間[a, b]で統一されてるし配列の添字の範囲も自由なので思想的にはシンプルだと思う。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/63
64: デフォルトの名無しさん [sage] 2025/09/22(月) 11:19:37.59 ID:XiCaSJNI 記述や可読性の差が大きい start..endの個数 【Rust】 end-start個 【Pascal】 end-start+1個 startからn個 【Rust】 start..(start+n) 【Pascal】 start..(start+n-1) このように間違えやすく見にくい+1や-1が 半開区間を採用のRustでは不要となる http://mevius.5ch.net/test/read.cgi/tech/1757733847/64
65: デフォルトの名無しさん [sage] 2025/09/22(月) 11:35:27.21 ID:0o6m1dEB Ruby の .. と ... はスッキリしているけど、老眼には辛いのよ。麻雀牌のニ萬と三萬よりさらに見分けづらいから。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/65
66: デフォルトの名無しさん [] 2025/09/22(月) 23:00:01.38 ID:AxN4Bvca >>59 ..は左右対称なので閉区間にしか見えず、それで右半開区間を表すのはバグの元となりやすい。 右半開区間は左右非対称の..<で表すのが妥当で、Swiftはそうしている。Swiftは閉区間が...で .が1個余分なのは良くないが。 閉区間を..で、右半開区間を..<で表せば、左半開区間を<..で、開区間を<..<で整合的に表せるし、 互いの見分けも容易だから合理的。もしC++が範囲演算子を導入するならこうしてもらいたい。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/66
67: デフォルトの名無しさん [sage] 2025/09/22(月) 23:50:00.52 ID:ci9fXj6N 前例に倣ったままにしとけめんどくせえ http://mevius.5ch.net/test/read.cgi/tech/1757733847/67
68: デフォルトの名無しさん [sage] 2025/09/23(火) 00:57:25.80 ID:0DVfn//v >>64 Rustの方式が優れてるね http://mevius.5ch.net/test/read.cgi/tech/1757733847/68
69: デフォルトの名無しさん [sage] 2025/09/23(火) 08:21:07.31 ID:ptEtOTO9 半開区間と閉区間の両方をサポートするならどちらも間違いようがない書き方にするべきだろう。Rustは閉区間を..=で表すなら半開区間は..<とでもすれば良かったな。 ..では「あれ? どっちだっけ?」と思ってしまう可能性がある。 http://mevius.5ch.net/test/read.cgi/tech/1757733847/69
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 223 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.008s