Qiita 7 - キータぞ、来たぞ、キータだぞー (291ﾚｽ)
上下前次1-新
40: 09/17(水)09:21 ID:0mQm0ojt(1/3) AAS
>>38
再帰を使わないシンプルな版を書いて主張すれば良い
41(1): 09/17(水)09:26 ID:MzfCTW9l(1) AAS
>>9
arr[n - i - 1]が不格好ではあるな
42: 09/17(水)10:55 ID:0mQm0ojt(2/3) AAS
>>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
}
43: 09/17(水)21:20 ID:0mQm0ojt(3/3) AAS
しまったー！
ElixirChip初お目見え会今日だったじゃーん
忘れてたわー！ざーんねーん！
とか言ったりして。
44(2): 09/17(水)22:01 ID:+QFNSyi5(1) AAS
配列などの各要素を巡る抽象化はイテレータだよ
抽象化の役割分担がわかりやすい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へ収集
}
このように抽象化された各パーツを組み合わせることで
可読性と安全性と高速実行を両立させている
45: 09/17(水)22:14 ID:Iu+PtAN6(1/2) AAS
改行CRとLFの真実：MS-DOS・BIOS・WIN10での挙動比較
外部ﾘﾝｸ:qiita.com
> Windows10
> '\r'で行頭に戻ることは確認できましたが、'\n'では下の行に下がるだけでなく行頭に自動的に戻されてしまうようです。
'\n'で行頭に移動するのはC言語の仕様で「\n 改行（new line）現表示位置を次の行の最初の位置に移動する。」となってるからで、WindowsではユニバーサルCランタイム (UCRT)が標準出力をテキストモードでオープンしてるため '\n' が '\r' + '\n' に変換されるからで、さらに最近の Windows Terminal は '\n' の動作が行頭に移動するようなってるので、とか説明せんといかんのかな、メンドい。
46(1): 09/17(水)22:54 ID:Iu+PtAN6(2/2) AAS
せっかくなので>>44の関数のベンチマークをしてみた。
外部ﾘﾝｸ:godbolt.org
reverse_value() のほうがちょっと速いのかな。
Rustって知らんけどblack_boxなんてあんのは面白いな。
47: 09/17(水)23:13 ID:2et8KGNs(1) AAS
>>46
参照型つまりアドレスたぶん64bitを収容と
i32型つまり32bitを収容のサイズの異なる比較になってしまってないかね？
48: 09/18(木)00:40 ID:sD2s9VAq(1/2) AAS
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
}
外部ﾘﾝｸ:godbolt.org
49: 09/18(木)01:41 ID:sD2s9VAq(2/2) AAS
出力の関数名間違ってたので訂正
外部ﾘﾝｸ:godbolt.org
50(1): 09/18(木)16:56 ID:E/kzpuoF(1) AAS
>>44
元のGoのコードがintの配列扱ってるのにジェネリック化してCloneで効率下げてるのなんで??
51: 09/18(木)17:45 ID:530bwAJW(1) AAS
>>50
Rustのジェネリックは効率を下げなくて従来の型指定した時と全く同じように動作することが特徴です
RustのCloneとは参照先から値を複製することです
例えば32bit数値の場合ならばCPUによるメモリ/レジスタ⇔メモリ/レジスタ間のロードやセーブが複製であって必ず行われることなので効率が下がることはありません
52(1): 09/18(木)23:44 ID:aCgogNys(1) AAS
Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
安全性などはついでのオマケ
53: 09/21(日)18:14 ID:MlvLaXh2(1) AAS
再帰派、息してる?
54: 09/21(日)19:59 ID:kxRRh56H(1) AAS
もれちんは再吃不能
55: 09/21(日)19:59 ID:hyRHfdTv(1) AAS
天才すぎて再起不能
56(1): 09/21(日)23:24 ID:wsaoMzy7(1) AAS
>>52
Rustは冗長なくせに変な略語や記号を多用するから可読性は低いよ。JavaとPerlの悪い所取り。
57: 09/21(日)23:46 ID:xj5a3FOL(1) AAS
>>56
変な記号？
記号は他の言語と同じ
Rustはコードの抽象化に成功していて可読性も保守性も高い
58(1): 09/22(月)07:39 ID:2d/wDxg8(1/3) AAS
Rustの..と..=の違いはセンスないなあと思った。Rubyの..と...も同様。
59(1): 09/22(月)08:00 ID:01ZECo7h(1) AAS
>>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の表記法がベストであることがよくわかる
60(1): 09/22(月)09:09 ID:2d/wDxg8(2/3) AAS
『Rust で書いたプログラムがなんか遅い』
Rustで..=を気軽にホイホイ使ってしまって「なんか遅い」と言ってる例。
抽象化の高い言語を使って何が起きてるか分かってないのも考えものだな。
61: 09/22(月)09:16 ID:Ow6is+fL(1) AAS
Rubyの .. はPascal と記法を合わせたもので、 ... は番兵を1つ外側に立たせておくくらいのイメージかな。
Rustの .. は、Pascac と記法を合わせることには拘らず、多用される番兵方式を少ない記号数で記述できる方が合理的という判断なんだろう。..= という記法のセンスの良し悪しは何とも言えないが。
どちらも内在的にはそれなりに合理的なんじゃないかな。
62: 09/22(月)09:59 ID:ytnqyum6(1) AAS
Pascal方式は1発進と相性がよく1..nがn個になる
Rust方式は0発進と相性がよく0..nがn個になる
indexが0発進になる言語はRust方式が便利
63: 09/22(月)10:11 ID:2d/wDxg8(3/3) AAS
Pascalは..もforも閉区間[a, b]で統一されてるし配列の添字の範囲も自由なので思想的にはシンプルだと思う。
64(4): 09/22(月)11:19 ID:XiCaSJNI(1) AAS
記述や可読性の差が大きい
start..endの個数
【Rust】 end-start個
【Pascal】 end-start+1個
startからn個
【Rust】 start..(start+n)
【Pascal】 start..(start+n-1)
このように間違えやすく見にくい+1や-1が
半開区間を採用のRustでは不要となる
65: 09/22(月)11:35 ID:0o6m1dEB(1) AAS
Ruby の .. と ... はスッキリしているけど、老眼には辛いのよ。麻雀牌のニ萬と三萬よりさらに見分けづらいから。
66(1): 09/22(月)23:00 ID:AxN4Bvca(1) AAS
>>59
..は左右対称なので閉区間にしか見えず、それで右半開区間を表すのはバグの元となりやすい。
右半開区間は左右非対称の..<で表すのが妥当で、Swiftはそうしている。Swiftは閉区間が...で
.が1個余分なのは良くないが。
閉区間を..で、右半開区間を..<で表せば、左半開区間を<..で、開区間を<..<で整合的に表せるし、
互いの見分けも容易だから合理的。もしC++が範囲演算子を導入するならこうしてもらいたい。
67: 09/22(月)23:50 ID:ci9fXj6N(1) AAS
前例に倣ったままにしとけめんどくせえ
68: 09/23(火)00:57 ID:0DVfn//v(1) AAS
>>64
Rustの方式が優れてるね
69(1): 09/23(火)08:21 ID:ptEtOTO9(1/2) AAS
半開区間と閉区間の両方をサポートするならどちらも間違いようがない書き方にするべきだろう。Rustは閉区間を..=で表すなら半開区間は..<とでもすれば良かったな。
..では「あれ? どっちだっけ?」と思ってしまう可能性がある。
上下前次1-新書関写板覧索設栞歴
あと 222 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.008s