Qiita 7 - キータぞ、来たぞ、キータだぞー (765ﾚｽ)
上下前次1-新
1: 2025/09/13(土)12:24 ID:mucntwOq(1) AAS
Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)
外部ﾘﾝｸ:qiita.com
Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。
外部ﾘﾝｸ[html]:internet.watch.impress.co.jp
前スレ Qiita
2chｽﾚ:tech
省10
2(1): 2025/09/14(日)01:56 ID:CZ0V8fQ4(1) AAS
『【Go】配列を再帰的に逆順にするサンプルコードを書いてみた』
> 再帰を使うことで、ループを使わずにエレガントに実装できる。
根本的なところで誤解してる人な模様。
3: 2025/09/14(日)02:53 ID:bGojT+ur(1) AAS
>>2
一般論として
再帰で表現した方が抽象度が高く理解しやすく定義そのまま表現できることが多い
特に末尾再帰をコンパイラがループへ変換してくれて実行効率が同等ならば全ての点で再帰による表記が勝る
4: 2025/09/14(日)12:10 ID:RhzWmJy7(1) AAS
入力配列と出力配列渡してループで処理するわ
5: 2025/09/14(日)12:59 ID:ZqIkDajJ(1/8) AAS
AA省
6(1): 2025/09/14(日)13:06 ID:ZqIkDajJ(2/8) AAS
記事のスライス操作版のコードは
> // ReverseArrayWithSlice はスライス操作で配列を逆順にする（再帰）
> func ReverseArrayWithSlice(arr []int) []int {
> // ベースケース: 要素が1つ以下なら逆順にする必要なし
> if len(arr) <= 1 {
> return arr
> }
>
> // 最初の要素を取り出し、残りを再帰的に逆順にしてから結合
> return append(ReverseArrayWithSlice(arr[1:]), arr[0])
省2
7(1): 2025/09/14(日)13:28 ID:ZqIkDajJ(3/8) AAS
そもそもの話として、ひとつの記事の中で複数の関数が引数だとか配列の内容を書き換えるのかどうかとか仕様が合ってないから比較になってないのよね。
8: 2025/09/14(日)13:42 ID:yOrWt/NI(1) AAS
>>7
問題はそこだね
ループでも書けるよとかの筋違いな批判は要らんて
9(3): 2025/09/14(日)14:21 ID:ZqIkDajJ(4/8) AAS
・引数は配列を渡すのみ
・内容を逆にした配列を返し、引数で渡した配列の内容は書き換えない
という条件にしたとして、繰り返しで書くより再帰のほうが良い書き方ができるだろうか?
func ReverseArrayWithFor(arr []int) []int {
n := len(arr)
result := make([]int, n)
for i := 0; i < n; i++ {
result[i] = arr[n - i - 1]
}
return result
省2
10: 2025/09/14(日)15:20 ID:wFXoVVHv(1) AAS
>>9
大昔からの古典すら知らない無知
LISPも知らないんだろうな
11: 2025/09/14(日)15:24 ID:ZqIkDajJ(5/8) AAS
GoとLISPの区別もつかない人とはなあｗ
12: 2025/09/14(日)15:30 ID:ZqIkDajJ(6/8) AAS
記事のスライス操作版のコードは
> // ReverseArrayWithSlice はスライス操作で配列を逆順にする（再帰）
> func ReverseArrayWithSlice(arr []int) []int {
> // ベースケース: 要素が1つ以下なら逆順にする必要なし
> if len(arr) <= 1 {
> return arr
> }
>
> // 最初の要素を取り出し、残りを再帰的に逆順にしてから結合
> return append(ReverseArrayWithSlice(arr[1:]), arr[0])
省5
13(1): 2025/09/14(日)15:35 ID:ZqIkDajJ(7/8) AAS
AA省
14: 2025/09/14(日)17:50 ID:ZqIkDajJ(8/8) AAS
ChatGPTに下記の質問投げたらそこそこ納得できる回答くれたわ。
「Go言語は末尾再帰はサポートされてるの?」
「末尾再帰最適化されないところでの再帰呼び出しは引数の範囲が不定だとスタックがどれくらい使われるかの予測はしづらいので要はGoでは引数の範囲が不定なところでの再帰呼び出しは使わない方が無難てことですね。」
「関数型言語で育った人とかで「再帰は繰り返し処理より常に正義」とかって人いるじゃない。ああいう人にはGoは辛いかもですね。」
「Lispにloopがサポートされても意地でも使わないとかの人いましたね。」
15: 2025/09/14(日)18:13 ID:pN1ZIB1N(1) AAS
>>6
何言ってんの爆速ですわ
16: 2025/09/14(日)18:45 ID:d1cvwZ2J(1/2) AAS
＞何言ってんの爆速ですわ
コードと実行結果のひとつでも挙げりゃ良いのだけど、それができない人がなんか言ってる感じｗ
17(2): 2025/09/14(日)19:42 ID:buQYk9+g(1) AAS
>>13
下手すぎ
最初に丸ごとcopyする時点でプログラミングのセンスがない
18: 2025/09/14(日)19:59 ID:d1cvwZ2J(2/2) AAS
丸ごとcopyしない>>17のセンスある実装に期待ｗ
19(3): 2025/09/14(日)21:05 ID:gAWV5uS0(1) AAS
いつも的外れな記事批判を繰り返している連投クンは本気でわからないようだな
元データを改変せずに新たに逆順を返す再帰関数を書きたいのならば例えばこうする
func ReverseArray(input []int) []int {
if len(input) == 0 {
return nil
} else {
return append(ReverseArray(input[1:]), input[0])
}
}
20: 2025/09/15(月)00:35 ID:aenReHhk(1/8) AAS
>>19と他のコードでベンチマークしてみた。要素数は10から10000。
外部ﾘﾝｸ:ideone.com
> 10:
> ReverseArray9: 0.000001
> ReverseArray13: 0.000000
> ReverseArray19: 0.000002
> 100:
> ReverseArray9: 0.000000
> ReverseArray13: 0.000000
> ReverseArray19: 0.000016
省8
21: 2025/09/15(月)00:39 ID:Wq0UyIVm(1) AAS
エンジニアならベンチ結果で語るべきだよな！
22: 2025/09/15(月)00:41 ID:oHygyuIm(1) AAS
末尾再帰を自動的にループ化しないシステムもあれば
appendするだけで毎回ムダに新たに別メモリを確保してしまうシステムもある
Goは最悪だと実証された
23: 2025/09/15(月)00:50 ID:cAmqpZFr(1) AAS
このクソ仕様がGoの敗因っぽいね
＞appendは毎回新たなスライスを生成します
24(1): 2025/09/15(月)08:10 ID:aenReHhk(2/8) AAS
AA省
25(1): 2025/09/15(月)08:16 ID:aenReHhk(3/8) AAS
ベンチマーク結果
外部ﾘﾝｸ:ideone.com
> 10:
> ReverseArray9: 0.000001
> ReverseArray13: 0.000001
> ReverseArray19: 0.000003
> ReverseArray24: 0.000000
> 100:
> ReverseArray9: 0.000000
> ReverseArray13: 0.000001
省13
26: 2025/09/15(月)08:27 ID:aenReHhk(4/8) AAS
ideone では Go のコンパイラが 1.12.1 と旧く、もっと新しい版(1.24.2)だと ReverseArray9 と ReverseArray24 の差は小さくなる模様。
外部ﾘﾝｸ:godbolt.org
出力コードも見ようとしたけどちょっと見る気起きないな。
main_ReverseArray19_pc0 の中で再帰呼び出ししてることは
> CALL main.ReverseArray19(SB)
確認したが。
27: 2025/09/15(月)08:41 ID:7N5dcPCF(1) AAS
一番シンプルにわかりやすい>>19を再帰呼び出しのままは厳しいな
appendするたびに作り直すらしいGoの仕様が足を引っ張ってるのだろうか
28: 2025/09/15(月)09:31 ID:G/lRv3X8(1) AAS
今のQiitaはこの程度の話すらコメ欄ではできないのがクソなんだよなあ。
29: 2025/09/15(月)12:47 ID:aenReHhk(5/8) AAS
なんか同じパラメータでの呼び出しを2回繰り返すと ReverseArray13 と ReverseArray19 だけ 2回目の速度が向上するな?
外部ﾘﾝｸ:ideone.com
> 1000:
> ReverseArray9: 0.000003
> ReverseArray13: 0.000089
> ReverseArray19: 0.000174
> ReverseArray24: 0.000007
> 1000:
> ReverseArray9: 0.000004
> ReverseArray13: 0.000005
省13
30: 2025/09/15(月)13:03 ID:aenReHhk(6/8) AAS
要素数を1000から1000刻みで増やしていくと6000でガクッとパフォーマンス落ちてるな。
外部ﾘﾝｸ:ideone.com
再帰呼び出しを深く行うことでスタックが足りなくなりスタック領域の拡張が行われそれでパフォーマンスが落ちてる気がする。
予めスタック領域が十分拡張されてれば ReverseArray13 と ReverseArray19 のパフォーマンスも 1回目から比較的マシになりそうな気がする。
31: 2025/09/15(月)13:16 ID:aenReHhk(7/8) AAS
AA省
32: 2025/09/15(月)13:23 ID:aenReHhk(8/8) AAS
>>25で
> ReverseArray24が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。
というのは多分間違いで、ReverseArray24 の前に実行している ReverseArray13 や ReverseArray19 のお陰でスタック領域が予め拡張されていたため ReverseArray24 の実行でスタック領域拡張処理が発生しなかったことがパフォーマンスが案外良かったことの原因と思われる。
33(1): 2025/09/15(月)19:24 ID:OSZOiNza(1) AAS
IDコロコロ切り替えてる人は自分の投稿に自信がないのかな
34: 2025/09/15(月)22:14 ID:wx2AhEF9(1) AAS
>>33
いや自信ないのはお前
いまはIDコロコロを言う流れでない
直前の投稿は同一IDで8件投稿してIDコロコロでない
安価なくIDコロコロと言われても何を言ってるのかわからない
お前が自分の投稿に自信ないのは空気を読めず日本語が不自由だから
35: 2025/09/16(火)01:27 ID:JSTZ1Kt/(1) AAS
IDコロコロに反応する人がいるのは面白いねえｗ
36: 2025/09/16(火)02:12 ID:NVXmEvhV(1) AAS
図っ星
37: 2025/09/16(火)09:08 ID:zaWo9xwV(1) AAS
Qiitaのコメ欄で有意義な議論ができない問題、バカなこと言ってる側が複垢使うとかで相手を攻撃的と通報する可能性までありそうだなｗ
38(1): 2025/09/16(火)19:41 ID:Wr/gNYaO(1) AAS
>>9や>>24のコードがダサくて>>19がシンプルなのは再帰の有無ではなくコードの抽象的な度合いが原因だと思う
39: 2025/09/17(水)08:59 ID:JW/5kEOI(1) AAS
数学的に言うと Σ(Sigma) は
再帰の方が抽象的なんか？
ループでも等価だと思うんだが
40: 2025/09/17(水)09:21 ID:0mQm0ojt(1/3) AAS
>>38
再帰を使わないシンプルな版を書いて主張すれば良い
41(1): 2025/09/17(水)09:26 ID:MzfCTW9l(1) AAS
>>9
arr[n - i - 1]が不格好ではあるな
42: 2025/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(1): 2025/09/17(水)21:20 ID:0mQm0ojt(3/3) AAS
しまったー！
ElixirChip初お目見え会今日だったじゃーん
忘れてたわー！ざーんねーん！
とか言ったりして。
44(2): 2025/09/17(水)22:01 ID:+QFNSyi5(1) AAS
配列などの各要素を巡る抽象化はイテレータだよ
抽象化の役割分担がわかりやすいRustで説明すると
今回の各要素の順番を逆順にしたベクタを作る関数はこうなる
fn reverse_value<T: Clone>(input: &[T]) -> Vec<T> {
input
.iter() // 各要素への参照を巡るイテレータ
.rev() // それを逆順に巡る
.cloned() // 各要素への参照から値を複製して値を得る
.collect() // それらの値を今回は返り型で指定のVecへ収集
}
省11
45: 2025/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): 2025/09/17(水)22:54 ID:Iu+PtAN6(2/2) AAS
せっかくなので>>44の関数のベンチマークをしてみた。
外部ﾘﾝｸ:godbolt.org
reverse_value() のほうがちょっと速いのかな。
Rustって知らんけどblack_boxなんてあんのは面白いな。
47: 2025/09/17(水)23:13 ID:2et8KGNs(1) AAS
>>46
参照型つまりアドレスたぶん64bitを収容と
i32型つまり32bitを収容のサイズの異なる比較になってしまってないかね？
48: 2025/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: 2025/09/18(木)01:41 ID:sD2s9VAq(2/2) AAS
出力の関数名間違ってたので訂正
外部ﾘﾝｸ:godbolt.org
50(1): 2025/09/18(木)16:56 ID:E/kzpuoF(1) AAS
>>44
元のGoのコードがintの配列扱ってるのにジェネリック化してCloneで効率下げてるのなんで??
51: 2025/09/18(木)17:45 ID:530bwAJW(1) AAS
>>50
Rustのジェネリックは効率を下げなくて従来の型指定した時と全く同じように動作することが特徴です
RustのCloneとは参照先から値を複製することです
例えば32bit数値の場合ならばCPUによるメモリ/レジスタ⇔メモリ/レジスタ間のロードやセーブが複製であって必ず行われることなので効率が下がることはありません
52(2): 2025/09/18(木)23:44 ID:aCgogNys(1) AAS
Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
安全性などはついでのオマケ
53: 2025/09/21(日)18:14 ID:MlvLaXh2(1) AAS
再帰派、息してる?
54: 2025/09/21(日)19:59 ID:kxRRh56H(1) AAS
もれちんは再吃不能
55: 2025/09/21(日)19:59 ID:hyRHfdTv(1) AAS
天才すぎて再起不能
56(1): 2025/09/21(日)23:24 ID:wsaoMzy7(1) AAS
>>52
Rustは冗長なくせに変な略語や記号を多用するから可読性は低いよ。JavaとPerlの悪い所取り。
57: 2025/09/21(日)23:46 ID:xj5a3FOL(1) AAS
>>56
変な記号？
記号は他の言語と同じ
Rustはコードの抽象化に成功していて可読性も保守性も高い
58(1): 2025/09/22(月)07:39 ID:2d/wDxg8(1/3) AAS
Rustの..と..=の違いはセンスないなあと思った。Rubyの..と...も同様。
59(1): 2025/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): 2025/09/22(月)09:09 ID:2d/wDxg8(2/3) AAS
『Rust で書いたプログラムがなんか遅い』
Rustで..=を気軽にホイホイ使ってしまって「なんか遅い」と言ってる例。
抽象化の高い言語を使って何が起きてるか分かってないのも考えものだな。
61: 2025/09/22(月)09:16 ID:Ow6is+fL(1) AAS
Rubyの .. はPascal と記法を合わせたもので、 ... は番兵を1つ外側に立たせておくくらいのイメージかな。
Rustの .. は、Pascac と記法を合わせることには拘らず、多用される番兵方式を少ない記号数で記述できる方が合理的という判断なんだろう。..= という記法のセンスの良し悪しは何とも言えないが。
どちらも内在的にはそれなりに合理的なんじゃないかな。
62: 2025/09/22(月)09:59 ID:ytnqyum6(1) AAS
Pascal方式は1発進と相性がよく1..nがn個になる
Rust方式は0発進と相性がよく0..nがn個になる
indexが0発進になる言語はRust方式が便利
63: 2025/09/22(月)10:11 ID:2d/wDxg8(3/3) AAS
Pascalは..もforも閉区間[a, b]で統一されてるし配列の添字の範囲も自由なので思想的にはシンプルだと思う。
64(4): 2025/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: 2025/09/22(月)11:35 ID:0o6m1dEB(1) AAS
Ruby の .. と ... はスッキリしているけど、老眼には辛いのよ。麻雀牌のニ萬と三萬よりさらに見分けづらいから。
66(1): 2025/09/22(月)23:00 ID:AxN4Bvca(1) AAS
>>59
..は左右対称なので閉区間にしか見えず、それで右半開区間を表すのはバグの元となりやすい。
右半開区間は左右非対称の..<で表すのが妥当で、Swiftはそうしている。Swiftは閉区間が...で
.が1個余分なのは良くないが。
閉区間を..で、右半開区間を..<で表せば、左半開区間を<..で、開区間を<..<で整合的に表せるし、
互いの見分けも容易だから合理的。もしC++が範囲演算子を導入するならこうしてもらいたい。
67: 2025/09/22(月)23:50 ID:ci9fXj6N(1) AAS
前例に倣ったままにしとけめんどくせえ
68: 2025/09/23(火)00:57 ID:0DVfn//v(1) AAS
>>64
Rustの方式が優れてるね
69(1): 2025/09/23(火)08:21 ID:ptEtOTO9(1/2) AAS
半開区間と閉区間の両方をサポートするならどちらも間違いようがない書き方にするべきだろう。Rustは閉区間を..=で表すなら半開区間は..<とでもすれば良かったな。
..では「あれ? どっちだっけ?」と思ってしまう可能性がある。
70: 2025/09/23(火)09:39 ID:BqTZOz5k(1) AAS
コード内に使われる記号列として許容できるのは .. と ... までかなぁ（ただし、両方を採用すると、ぱっと見では見分けがつきにくいという問題がある）。..= とか ..< は、もちろんそれなりに合理的な考慮の上で採用されたんだろうけど、もう見た目で受け付けないわ。
Rustも基本的には .. を使えってことなんじゃない？ 一応、..= も用意してあるけど、どうしても必要なケースがあるなら使ってねくらいの位置付けに過ぎないと思う。
71: 2025/09/23(火)10:03 ID:U5/crNyE(1) AAS
範囲を表すのは .. だけにして、含まれない端点にはマーカー文字をつけるという方法もありそうだけど、目立つ採用例がないってことはたぶん問題があるんだろうね。
1 .. 5 → 1から5まで
1 .. 5^ → 1から4まで
72: 2025/09/23(火)15:33 ID:rmbzdEQk(1) AAS
>>64
一見すると素人には閉区間が便利に見えてしまうけどそのような複雑化する害が多すぎるんだよな
プログラミング言語としては半開区間が最適だ
73: 2025/09/23(火)17:38 ID:ptEtOTO9(2/2) AAS
IDコロコロ君の投稿を容易に見分けられるようになってしまい残念な気持ち。
74(1): 2025/09/23(火)19:08 ID:zU/q7UQ3(1/2) AAS
>>60
半開区間イテレータはゼロコスト抽象化が可能だけど、
閉区間イテレータはその仕様上どうしても枯渇フラグが別途必要となるため、
データサイズの増大とコード実行が遅くなってしまうからね。
閉区間イテレータは効率を求める場面ではタブーと教えるしかないよ。
75: 2025/09/23(火)19:13 ID:zU/q7UQ3(2/2) AAS
>>69
Rustはもともと効率のいい半開区間イテレータ「..」しかなくて、「..」以外の仕様でも半開区間が採用されているため、間違えることがないようにできているよ。
動作が遅くてもいいから欲しいとの要望により、閉区間イテレータ「..=」を後から追加したんだよ。
速度を気にする場所でこの変な記号「..=」を使うのは要注意と覚えれば大丈夫。
76: 2025/09/24(水)04:44 ID:NxVT75eJ(1) AAS
歴史的な事情で対称性の悪い表記が存在するのって（その歴史を知らないと納得できないから）負の遺産だよね。
77(1): 2025/09/24(水)09:37 ID:iLsvaA+I(1) AAS
古い言語は仕方ないね
新たな言語を作るならば歴史的な知見で誰もが半開区間ベースの言語仕様にするでしょう
①プログラムを書く上で便利 理由>>64
②実行効率も良い 理由>>74
78: 2025/09/25(木)07:39 ID:rGEl0fht(1) AAS
Pythonのrange(1,5)も1,2,3,4を意味する半開区間だよ
79: 2025/09/25(木)08:04 ID:+zec6Qog(1) AAS
半開区間と閉区間の両方をサポートしてて紛らわしい表記になってるのが残念という話が理解できない人かな
80: 2025/09/25(木)10:55 ID:qSe6mg1h(1/2) AAS
Rustみたいに標準ライブラリ全体の仕様を半開区間で統一すれば間違えることもなく悩まずに済むのに
81(1): 2025/09/25(木)11:16 ID:Wia1VUCr(1) AAS
要らない..=をサポートしてしまった為に糞化してしまったRust哀れ
82(2): 2025/09/25(木)11:29 ID:qSe6mg1h(2/2) AAS
>>81
糞化って何？
意味がわからない
83: 2025/09/26(金)10:22 ID:UkFmEBgM(1) AAS
確かに元から糞なものが糞化とは腹が痛い
84: 2025/09/26(金)12:42 ID:X9xxY5lJ(1) AAS
>>82
「糞化って何？」って何？
意味がわからない
元から糞なものが糞になって糞化したと言っても意味が通る
85: 2025/09/26(金)16:46 ID:IX+dZCHo(1) AAS
>>82
ウンコになったってことだよ
86: 2025/09/26(金)20:33 ID:/tXGYc/j(1) AAS
>>64
それよりもっと重要なことが抜けてるぞ
Pascal方式で避けられないそれら+1や-1がRust方式では不要となるだけでなく
Rust方式では長さ0を特別扱いせずに自然に扱えることが最大の特徴
Rust方式は長さnがstart..(start + n)であるため
長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える
Pascal方式は長さnがstart..(start + n -1)であるため
長さ0はstart..(start -1)になり左右逆転してしまう
そのためこの不格好な逆転状態を長さ0とみなして扱うか
場合分けして長さ0を扱わないようにするか
省1
87(2): 2025/09/27(土)00:25 ID:XX0uOJLH(1/4) AAS
＞長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える
長さ0を表現するのにstartが具体的な値持ってて自然てどういう理屈?
88(1): 2025/09/27(土)00:31 ID:lQv27qFK(1) AAS
>>87
長さ1や長さ2がstart違ってあちこちにあるように
長さ0もstart違ってあちこちに存在する
89: 2025/09/27(土)00:43 ID:XX0uOJLH(2/4) AAS
>>88
Pascalでstartの違う長さ0表して便利な例挙げてみて
90(2): 2025/09/27(土)00:55 ID:B/IRYC2K(1/4) AAS
>>87
Rustの..は性質の良い半開区間なので、
例えばstart..endを途中のmiddleの位置で分割すると、start..middleとmiddle..endの二つに綺麗に分かれる性質も持っているよ。
そしてそのmiddleの決定算出結果が処理内容や処理状況によっては、たまたまstartと一致することも出てくる。
その時、start..middleとmiddle..endの二つは、start..startとstart..endの二つに分かれて前者は長さ0になるね。
Rustでのプログラミングでも実際にこれはよく起きるよ。
91(2): 2025/09/27(土)01:43 ID:XX0uOJLH(3/4) AAS
>>90
区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。
92(1): 2025/09/27(土)01:48 ID:XX0uOJLH(4/4) AAS
閉区間と半開区間のどちらにメリットがある場合もあり、Rustも閉区間をサポートしてるのに半開区間のみを持ち上げてるのは見識が狭いな。
93: 2025/09/27(土)02:17 ID:B/IRYC2K(2/4) AAS
>>91
区間には必ずスタート位置を伴いますね。
そこから長さが2だったり長さが1だったり長さが0だったりするわけです。
長さ0の時だけスタート位置が無いのは不自然でしょう。
>>92
良い性質を備えていてメリットがあるのは半開区間でしょう。
Rustの標準APIは区間分割split_atなどでも半開区間を前提として処理されます。
94(1): 2025/09/27(土)02:20 ID:u3EkYZLQ(1) AAS
『fast inverse square root (高速逆平方根) のようなトリックまとめ』
未定義動作コードの見本市みたいな記事。
C言語知りませんアピールか。
95: 2025/09/27(土)07:25 ID:rUQ4UupW(1) AAS
C言語なんて動きゃいいんだよ動きゃ
96: 2025/09/27(土)08:53 ID:ItgajmGE(1) AAS
動きゃいいんだよ動きゃなんて言語でカーネルを作ってほしくない
97: 2025/09/27(土)12:15 ID:HCtgOBXK(1) AAS
古いのから新しいのまであらゆるCPUで動きゃいいんだよ動きゃ
98: 2025/09/27(土)13:57 ID:HvNJXk8w(1) AAS
＞動きゃいいんだよ動きゃ
動くかわからん未定義動作のコードにこういうこと言う奴は馬鹿
99: 2025/09/27(土)16:57 ID:1KNVq9e2(1) AAS
特定のCPU/GPU環境と断ってる
C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え
100(1): 2025/09/27(土)17:02 ID:mMYsldco(1) AAS
CとC++はこの手の気持ち悪いオジサン湧くからほんと無理
上下前次1-新書関写板覧索設栞歴
あと 665 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.038s