Qiita 7 - キータぞ、来たぞ、キータだぞー (151ﾚｽ)
上下前次1-新
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
1: 2025/09/13(土) 12:24:07.83 ID:mucntwOq(1)調 AAS
Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)
外部ﾘﾝｸ:qiita.com
Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。
外部ﾘﾝｸ[html]:internet.watch.impress.co.jp
前スレ Qiita
2chｽﾚ:tech
Qiita 2 - キータぞ、来たぞ、キータだぞー
2chｽﾚ:tech
Qiita 3 - キータぞ、来たぞ、キータだぞー
2chｽﾚ:tech
Qiita 4 - キータぞ、来たぞ、キータだぞー
2chｽﾚ:tech
Qiita 5 - キータぞ、来たぞ、キータだぞー
2chｽﾚ:tech
Qiita 6 - キータぞ、来たぞ、キータだぞー
2chｽﾚ:tech
24(1): 2025/09/15(月) 08:10:37.10 ID:aenReHhk(2/8)調 AA×
>>17
25(1): 2025/09/15(月) 08:16:11.29 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
> ReverseArray19: 0.000024
> ReverseArray24: 0.000001
> 1000:
> ReverseArray9: 0.000003
> ReverseArray13: 0.000061
> ReverseArray19: 0.000143
> ReverseArray24: 0.000006
> 10000:
> ReverseArray9: 0.000013
> ReverseArray13: 0.000446
> ReverseArray19: 0.001487
> ReverseArray24: 0.000060
ReverseArray24が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。
26: 2025/09/15(月) 08:27:46.98 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:05.40 ID:7N5dcPCF(1)調 AAS
一番シンプルにわかりやすい>>19を再帰呼び出しのままは厳しいな
appendするたびに作り直すらしいGoの仕様が足を引っ張ってるのだろうか
28: 2025/09/15(月) 09:31:01.39 ID:G/lRv3X8(1)調 AAS
今のQiitaはこの程度の話すらコメ欄ではできないのがクソなんだよなあ。
29: 2025/09/15(月) 12:47:17.00 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
> ReverseArray19: 0.000016
> ReverseArray24: 0.000007
> 10000:
> ReverseArray9: 0.000018
> ReverseArray13: 0.000574
> ReverseArray19: 0.001747
> ReverseArray24: 0.000059
> 10000:
> ReverseArray9: 0.000024
> ReverseArray13: 0.000035
> ReverseArray19: 0.000207
> ReverseArray24: 0.000055
キャッシュの影響ではなさそうだがなんぞコレ? こういうのは楽しい。
30: 2025/09/15(月) 13:03:08.76 ID:aenReHhk(6/8)調 AAS
要素数を1000から1000刻みで増やしていくと6000でガクッとパフォーマンス落ちてるな。
外部ﾘﾝｸ:ideone.com
再帰呼び出しを深く行うことでスタックが足りなくなりスタック領域の拡張が行われそれでパフォーマンスが落ちてる気がする。
予めスタック領域が十分拡張されてれば ReverseArray13 と ReverseArray19 のパフォーマンスも 1回目から比較的マシになりそうな気がする。
31: 2025/09/15(月) 13:16:02.23 ID:aenReHhk(7/8)調 AA×
外部ﾘﾝｸ:ideone.com
32: 2025/09/15(月) 13:23:08.72 ID:aenReHhk(8/8)調 AAS
>>25で
> ReverseArray24が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。
というのは多分間違いで、ReverseArray24 の前に実行している ReverseArray13 や ReverseArray19 のお陰でスタック領域が予め拡張されていたため ReverseArray24 の実行でスタック領域拡張処理が発生しなかったことがパフォーマンスが案外良かったことの原因と思われる。
33(1): 2025/09/15(月) 19:24:06.27 ID:OSZOiNza(1)調 AAS
IDコロコロ切り替えてる人は自分の投稿に自信がないのかな
34: 2025/09/15(月) 22:14:31.00 ID:wx2AhEF9(1)調 AAS
>>33
いや自信ないのはお前
いまはIDコロコロを言う流れでない
直前の投稿は同一IDで8件投稿してIDコロコロでない
安価なくIDコロコロと言われても何を言ってるのかわからない
お前が自分の投稿に自信ないのは空気を読めず日本語が不自由だから
35: 2025/09/16(火) 01:27:30.19 ID:JSTZ1Kt/(1)調 AAS
IDコロコロに反応する人がいるのは面白いねえｗ
36: 2025/09/16(火) 02:12:35.47 ID:NVXmEvhV(1)調 AAS
図っ星
37: 2025/09/16(火) 09:08:34.57 ID:zaWo9xwV(1)調 AAS
Qiitaのコメ欄で有意義な議論ができない問題、バカなこと言ってる側が複垢使うとかで相手を攻撃的と通報する可能性までありそうだなｗ
38(1): 2025/09/16(火) 19:41:50.97 ID:Wr/gNYaO(1)調 AAS
>>9や>>24のコードがダサくて>>19がシンプルなのは再帰の有無ではなくコードの抽象的な度合いが原因だと思う
39: 2025/09/17(水) 08:59:29.24 ID:JW/5kEOI(1)調 AAS
数学的に言うと Σ(Sigma) は
再帰の方が抽象的なんか？
ループでも等価だと思うんだが
40: 2025/09/17(水) 09:21:49.27 ID:0mQm0ojt(1/3)調 AAS
>>38
再帰を使わないシンプルな版を書いて主張すれば良い
41(1): 2025/09/17(水) 09:26:43.33 ID:MzfCTW9l(1)調 AAS
>>9
arr[n - i - 1]が不格好ではあるな
42: 2025/09/17(水) 10:55:53.14 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: 2025/09/17(水) 21:20:35.77 ID:0mQm0ojt(3/3)調 AAS
しまったー！
ElixirChip初お目見え会今日だったじゃーん
忘れてたわー！ざーんねーん！
とか言ったりして。
44(2): 2025/09/17(水) 22:01:15.40 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: 2025/09/17(水) 22:14:21.95 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:27.39 ID:Iu+PtAN6(2/2)調 AAS
せっかくなので>>44の関数のベンチマークをしてみた。
外部ﾘﾝｸ:godbolt.org
reverse_value() のほうがちょっと速いのかな。
Rustって知らんけどblack_boxなんてあんのは面白いな。
47: 2025/09/17(水) 23:13:57.67 ID:2et8KGNs(1)調 AAS
>>46
参照型つまりアドレスたぶん64bitを収容と
i32型つまり32bitを収容のサイズの異なる比較になってしまってないかね？
48: 2025/09/18(木) 00:40:20.60 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:40.32 ID:sD2s9VAq(2/2)調 AAS
出力の関数名間違ってたので訂正
外部ﾘﾝｸ:godbolt.org
50(1): 2025/09/18(木) 16:56:30.82 ID:E/kzpuoF(1)調 AAS
>>44
元のGoのコードがintの配列扱ってるのにジェネリック化してCloneで効率下げてるのなんで??
51: 2025/09/18(木) 17:45:09.89 ID:530bwAJW(1)調 AAS
>>50
Rustのジェネリックは効率を下げなくて従来の型指定した時と全く同じように動作することが特徴です
RustのCloneとは参照先から値を複製することです
例えば32bit数値の場合ならばCPUによるメモリ/レジスタ⇔メモリ/レジスタ間のロードやセーブが複製であって必ず行われることなので効率が下がることはありません
52(1): 2025/09/18(木) 23:44:30.13 ID:aCgogNys(1)調 AAS
Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
安全性などはついでのオマケ
53: 2025/09/21(日) 18:14:05.85 ID:MlvLaXh2(1)調 AAS
再帰派、息してる?
54: 2025/09/21(日) 19:59:36.62 ID:kxRRh56H(1)調 AAS
もれちんは再吃不能
55: 2025/09/21(日) 19:59:57.80 ID:hyRHfdTv(1)調 AAS
天才すぎて再起不能
56(1): 2025/09/21(日) 23:24:29.32 ID:wsaoMzy7(1)調 AAS
>>52
Rustは冗長なくせに変な略語や記号を多用するから可読性は低いよ。JavaとPerlの悪い所取り。
57: 2025/09/21(日) 23:46:21.39 ID:xj5a3FOL(1)調 AAS
>>56
変な記号？
記号は他の言語と同じ
Rustはコードの抽象化に成功していて可読性も保守性も高い
58(1): 2025/09/22(月) 07:39:29.97 ID:2d/wDxg8(1/3)調 AAS
Rustの..と..=の違いはセンスないなあと思った。Rubyの..と...も同様。
59(1): 2025/09/22(月) 08:00:31.81 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:30.72 ID:2d/wDxg8(2/3)調 AAS
『Rust で書いたプログラムがなんか遅い』
Rustで..=を気軽にホイホイ使ってしまって「なんか遅い」と言ってる例。
抽象化の高い言語を使って何が起きてるか分かってないのも考えものだな。
61: 2025/09/22(月) 09:16:25.38 ID:Ow6is+fL(1)調 AAS
Rubyの .. はPascal と記法を合わせたもので、 ... は番兵を1つ外側に立たせておくくらいのイメージかな。
Rustの .. は、Pascac と記法を合わせることには拘らず、多用される番兵方式を少ない記号数で記述できる方が合理的という判断なんだろう。..= という記法のセンスの良し悪しは何とも言えないが。
どちらも内在的にはそれなりに合理的なんじゃないかな。
62: 2025/09/22(月) 09:59:26.76 ID:ytnqyum6(1)調 AAS
Pascal方式は1発進と相性がよく1..nがn個になる
Rust方式は0発進と相性がよく0..nがn個になる
indexが0発進になる言語はRust方式が便利
63: 2025/09/22(月) 10:11:48.70 ID:2d/wDxg8(3/3)調 AAS
Pascalは..もforも閉区間[a, b]で統一されてるし配列の添字の範囲も自由なので思想的にはシンプルだと思う。
64(4): 2025/09/22(月) 11:19:37.59 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:27.21 ID:0o6m1dEB(1)調 AAS
Ruby の .. と ... はスッキリしているけど、老眼には辛いのよ。麻雀牌のニ萬と三萬よりさらに見分けづらいから。
66: 2025/09/22(月) 23:00:01.38 ID:AxN4Bvca(1)調 AAS
>>59
..は左右対称なので閉区間にしか見えず、それで右半開区間を表すのはバグの元となりやすい。
右半開区間は左右非対称の..<で表すのが妥当で、Swiftはそうしている。Swiftは閉区間が...で
.が1個余分なのは良くないが。
閉区間を..で、右半開区間を..<で表せば、左半開区間を<..で、開区間を<..<で整合的に表せるし、
互いの見分けも容易だから合理的。もしC++が範囲演算子を導入するならこうしてもらいたい。
67: 2025/09/22(月) 23:50:00.52 ID:ci9fXj6N(1)調 AAS
前例に倣ったままにしとけめんどくせえ
68: 2025/09/23(火) 00:57:25.80 ID:0DVfn//v(1)調 AAS
>>64
Rustの方式が優れてるね
69(1): 2025/09/23(火) 08:21:07.31 ID:ptEtOTO9(1/2)調 AAS
半開区間と閉区間の両方をサポートするならどちらも間違いようがない書き方にするべきだろう。Rustは閉区間を..=で表すなら半開区間は..<とでもすれば良かったな。
..では「あれ? どっちだっけ?」と思ってしまう可能性がある。
70: 2025/09/23(火) 09:39:04.17 ID:BqTZOz5k(1)調 AAS
コード内に使われる記号列として許容できるのは .. と ... までかなぁ（ただし、両方を採用すると、ぱっと見では見分けがつきにくいという問題がある）。..= とか ..< は、もちろんそれなりに合理的な考慮の上で採用されたんだろうけど、もう見た目で受け付けないわ。
Rustも基本的には .. を使えってことなんじゃない？ 一応、..= も用意してあるけど、どうしても必要なケースがあるなら使ってねくらいの位置付けに過ぎないと思う。
71: 2025/09/23(火) 10:03:23.14 ID:U5/crNyE(1)調 AAS
範囲を表すのは .. だけにして、含まれない端点にはマーカー文字をつけるという方法もありそうだけど、目立つ採用例がないってことはたぶん問題があるんだろうね。
1 .. 5 → 1から5まで
1 .. 5^ → 1から4まで
72: 2025/09/23(火) 15:33:33.09 ID:rmbzdEQk(1)調 AAS
>>64
一見すると素人には閉区間が便利に見えてしまうけどそのような複雑化する害が多すぎるんだよな
プログラミング言語としては半開区間が最適だ
73: 2025/09/23(火) 17:38:31.18 ID:ptEtOTO9(2/2)調 AAS
IDコロコロ君の投稿を容易に見分けられるようになってしまい残念な気持ち。
74(1): 2025/09/23(火) 19:08:43.70 ID:zU/q7UQ3(1/2)調 AAS
>>60
半開区間イテレータはゼロコスト抽象化が可能だけど、
閉区間イテレータはその仕様上どうしても枯渇フラグが別途必要となるため、
データサイズの増大とコード実行が遅くなってしまうからね。
閉区間イテレータは効率を求める場面ではタブーと教えるしかないよ。
75: 2025/09/23(火) 19:13:50.59 ID:zU/q7UQ3(2/2)調 AAS
>>69
Rustはもともと効率のいい半開区間イテレータ「..」しかなくて、「..」以外の仕様でも半開区間が採用されているため、間違えることがないようにできているよ。
動作が遅くてもいいから欲しいとの要望により、閉区間イテレータ「..=」を後から追加したんだよ。
速度を気にする場所でこの変な記号「..=」を使うのは要注意と覚えれば大丈夫。
76: 2025/09/24(水) 04:44:51.44 ID:NxVT75eJ(1)調 AAS
歴史的な事情で対称性の悪い表記が存在するのって（その歴史を知らないと納得できないから）負の遺産だよね。
77(1): 2025/09/24(水) 09:37:45.93 ID:iLsvaA+I(1)調 AAS
古い言語は仕方ないね
新たな言語を作るならば歴史的な知見で誰もが半開区間ベースの言語仕様にするでしょう
①プログラムを書く上で便利 理由>>64
②実行効率も良い 理由>>74
78: 2025/09/25(木) 07:39:21.36 ID:rGEl0fht(1)調 AAS
Pythonのrange(1,5)も1,2,3,4を意味する半開区間だよ
79: 2025/09/25(木) 08:04:45.13 ID:+zec6Qog(1)調 AAS
半開区間と閉区間の両方をサポートしてて紛らわしい表記になってるのが残念という話が理解できない人かな
80: 2025/09/25(木) 10:55:22.03 ID:qSe6mg1h(1/2)調 AAS
Rustみたいに標準ライブラリ全体の仕様を半開区間で統一すれば間違えることもなく悩まずに済むのに
81(1): 2025/09/25(木) 11:16:52.45 ID:Wia1VUCr(1)調 AAS
要らない..=をサポートしてしまった為に糞化してしまったRust哀れ
82(2): 2025/09/25(木) 11:29:57.30 ID:qSe6mg1h(2/2)調 AAS
>>81
糞化って何？
意味がわからない
83: 2025/09/26(金) 10:22:57.69 ID:UkFmEBgM(1)調 AAS
確かに元から糞なものが糞化とは腹が痛い
84: 2025/09/26(金) 12:42:08.13 ID:X9xxY5lJ(1)調 AAS
>>82
「糞化って何？」って何？
意味がわからない
元から糞なものが糞になって糞化したと言っても意味が通る
85: 2025/09/26(金) 16:46:57.32 ID:IX+dZCHo(1)調 AAS
>>82
ウンコになったってことだよ
86: 2025/09/26(金) 20:33:46.74 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を扱わないようにするか
場合分けして長さ0の時にnullとかnilとか空リストなど特別扱いする形になる
87(2): 2025/09/27(土) 00:25:32.78 ID:XX0uOJLH(1/4)調 AAS
＞長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える
長さ0を表現するのにstartが具体的な値持ってて自然てどういう理屈?
88(1): 2025/09/27(土) 00:31:44.56 ID:lQv27qFK(1)調 AAS
>>87
長さ1や長さ2がstart違ってあちこちにあるように
長さ0もstart違ってあちこちに存在する
89: 2025/09/27(土) 00:43:10.07 ID:XX0uOJLH(2/4)調 AAS
>>88
Pascalでstartの違う長さ0表して便利な例挙げてみて
90(2): 2025/09/27(土) 00:55:46.18 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:57.58 ID:XX0uOJLH(3/4)調 AAS
>>90
区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。
92(1): 2025/09/27(土) 01:48:32.95 ID:XX0uOJLH(4/4)調 AAS
閉区間と半開区間のどちらにメリットがある場合もあり、Rustも閉区間をサポートしてるのに半開区間のみを持ち上げてるのは見識が狭いな。
93: 2025/09/27(土) 02:17:11.42 ID:B/IRYC2K(2/4)調 AAS
>>91
区間には必ずスタート位置を伴いますね。
そこから長さが2だったり長さが1だったり長さが0だったりするわけです。
長さ0の時だけスタート位置が無いのは不自然でしょう。
>>92
良い性質を備えていてメリットがあるのは半開区間でしょう。
Rustの標準APIは区間分割split_atなどでも半開区間を前提として処理されます。
94(1): 2025/09/27(土) 02:20:12.82 ID:u3EkYZLQ(1)調 AAS
『fast inverse square root (高速逆平方根) のようなトリックまとめ』
未定義動作コードの見本市みたいな記事。
C言語知りませんアピールか。
95: 2025/09/27(土) 07:25:01.25 ID:rUQ4UupW(1)調 AAS
C言語なんて動きゃいいんだよ動きゃ
96: 2025/09/27(土) 08:53:18.36 ID:ItgajmGE(1)調 AAS
動きゃいいんだよ動きゃなんて言語でカーネルを作ってほしくない
97: 2025/09/27(土) 12:15:10.22 ID:HCtgOBXK(1)調 AAS
古いのから新しいのまであらゆるCPUで動きゃいいんだよ動きゃ
98: 2025/09/27(土) 13:57:37.59 ID:HvNJXk8w(1)調 AAS
＞動きゃいいんだよ動きゃ
動くかわからん未定義動作のコードにこういうこと言う奴は馬鹿
99: 2025/09/27(土) 16:57:30.37 ID:1KNVq9e2(1)調 AAS
特定のCPU/GPU環境と断ってる
C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え
100(1): 2025/09/27(土) 17:02:10.01 ID:mMYsldco(1)調 AAS
CとC++はこの手の気持ち悪いオジサン湧くからほんと無理
101: 2025/09/27(土) 17:19:12.43 ID:CHztWjoA(1/2)調 AAS
>>94
その記事「特定のCPU/GPU環境」を書かないのが片手落ちやな
102(1): 2025/09/27(土) 20:09:28.90 ID:16nWnOPC(1)調 AAS
>>100
直前に出たRustとC/C++の違いは
C/C++はお前のようなバカにも理解できるように分かりやすく話してあげてることだぞ
103(1): 2025/09/27(土) 20:36:16.39 ID:jktxSQ82(1/4)調 AAS
>>77
半開区間で書く方が便利な場合があることを誰も否定してはいないだろう。一方、閉区間で
書く方が便利な場合もある。例えば1からnまでの自然数を表示したいときがそうだが、
半開区間しかないPythonではfor i in range(1, n + 1): print(i)なんてひねくれた書き方を
強要されるし効率も悪い（Pythonで効率を云々しても意味ないが）。だから、半開区間と
閉区間の両方の記法を提供するのが良い。
半開区間を表すのに左右対称な..を使うのは紛らわしいので不適切。Pascalなどで..で閉区間を
表す慣用が定着していたにもかかわらず、..で半開区間を表す愚行を最初にやらかしたのはDか。
その前車の轍をC#, Go, Rustが踏んでしまった。特に.NET兄弟のF#とPowerShellが..を閉区間で
既に使っていたのにC#が半開区間を表すのに..を導入してしまったのは大きな誤りだった。
Dはほぼ死語と化したから、..で半開区間を表す不適切な記法も消え去るべきだな。
104: 2025/09/27(土) 20:44:14.86 ID:CHztWjoA(2/2)調 AAS
閉区間ｲﾗﾈｴ
105(1): 2025/09/27(土) 21:04:56.86 ID:h+m11Qj8(1/3)調 AAS
閉区間を表す記号を用意すべきかどうかについてはそれぞれ考え方の違いがあるんだなと思うが、.. は左右対称だから閉区間にすべきというのは正直よく分からん理由付けだわ。Pascalだってそんな理由で .. を閉区間の記号にしたわけではないと思うが。
106(1): 2025/09/27(土) 21:10:34.65 ID:B/IRYC2K(3/4)調 AAS
>>103
多くの言語が半開区間を基本として扱っている理由は、半開区間だけが優れた性質を備えていてプログラミングに適しているためだよ。
半開区間だけが、start～endは長さ start - endを示し、startから長さnはstart～(start + n)になり、長さ0をstart～startで示すことができ、start～endをstart～middleとmiddle～endの2つに分割できる。
間違えた古い言語に習うことなく、半開区間をstart:endやstart..endなど簡素に記述するそれらの言語C# Go Rust Pythonなどが正しいよ。
JavaScriptもarr.slice(start, end)は半開区間であり、半開区間を基本とする言語が多数派だね。
107: 2025/09/27(土) 21:12:07.66 ID:PCqkgGFG(1)調 AAS
＞特定のCPU/GPU環境と断ってる
＞C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え
記事のコードがダメのはC言語の仕様として未定義動作と規定されてることをやってるからで特定CPU関係ないよ。
108(2): 2025/09/27(土) 21:17:11.52 ID:jktxSQ82(2/4)調 AAS
>>105
数学での表記も閉区間と開区間の記号は左右対称で、半開区間は左右非対称。
閉区間[a, b] 開区間(a, b) 左半開区間(a, b] 右半開区間[a, b)
..は閉区間にしか見えない。右半開区間は..<か..~にすべきなのにたった1文字をケチって
バグを呼び込むのは愚行としか言いようがない。
>>106
for i in range(1, n + 1): print(i)がプログラミングに適しているとでも?
109(1): 2025/09/27(土) 21:29:49.40 ID:B/IRYC2K(4/4)調 AAS
>>108
それら現在メジャーな各言語の、range(srart, end)もslice(start, end)もstart:endもstart..endも全て半開区間を意味しているため、間違える人はいなくて、初心者もすぐ理解して誰も困っていないよ。
0からn個がrange(0, n)
1からn個がrange(1, n + 1)
2からn個がrange(2, n + 2)
とてもわかりやすくなっているね。
110: 2025/09/27(土) 21:50:13.15 ID:jktxSQ82(3/4)調 AAS
>>109
そんなものがわかりやすいわけないだろ。2からnまでの自然数を表示したい場合にはn - 1個だから
右端はn - 1 + 2 = n + 1でrange(2, n + 1)なんていちいち計算するのかw
mからn個ならC#のEnuemerable.Rangeが分かりやすい。
0からn個がEnuemerable.Range(0, n)
1からn個がEnuemerable.Range(1, n)
2からn個がEnuemerable.Range(2, n)
理解していなくて間違えるのではなく、理解しているが左右対称の見た目につられてうっかり間違えやすい。
それなのにわずか1文字をケチるのは愚行。
111(1): 2025/09/27(土) 21:54:38.07 ID:h+m11Qj8(2/3)調 AAS
① 多用される半開区間を少ない記号で書けるよう .. を半開区間の記号にしました。
② Pascal以来の伝統を重視して .. を閉区間の記号にしました。
③ 閉区間の記号は数学記号に倣って左右対称であるべきなので .. を閉区間の記号にしました。
自分は、説得力を感じる度合いとしては① >= ② >>> ③ かな。③ははっきり言ってパラノイアの戯言レベルの物言いにしか思えない。
また、半開区間の記号を ..< とか ..〜 のような冗長で読みにくい記号にする前提なら、それが .. を閉区間の記号にしたくない最大の理由になるかな。Pascalのように閉区間の記号しか設けていないのなら仕方ないが、開区間と閉区間の記号を両方用意するなら、開区間の記号の方をスッキリした記号にして欲しい。Rubyの .. と... で許容範囲ギリギリくらい。
112: 2025/09/27(土) 22:08:37.36 ID:jktxSQ82(4/4)調 AAS
>>111
意味がある記号を書くのを冗長とは言わない。消すのを愚行という。Pythonが意味がある{}を消したのも愚行。
そんなに文字数を減らしたいなら半開区間の記号を.~にしたらどうか。
113: 2025/09/27(土) 22:45:20.51 ID:fM3CYn91(1)調 AAS
> 閉区間[a, b] 開区間(a, b) 左半開区間(a, b] 右半開区間[a, b)
これでいうとrust方式は一貫性の点で詰んでないか？
閉区間[a, b] a..=b
開区間(a, b) ???
右半開区間[a, b) a..b
左半開区間(a, b] ???
pascal方式だと以下のように拡張しうる余地がある
閉区間[a, b] a..b
開区間(a, b) a<..<b
右半開区間[a, b) a..<b
左半開区間(a, b] a<..b
114(1): 2025/09/27(土) 23:23:15.70 ID:h+m11Qj8(3/3)調 AAS
このスレでパラノイアの妄執を開陳されてもなぁ。
..< とか <..< とかで「一貫してるぞ、わーい」って喜べるの貴方くらいだよ。
115(2): 2025/09/27(土) 23:40:53.38 ID:xS2lIG/M(1)調 AAS
Rustは非常にシンプルで
最も多用されて使いやすい半開区間
従来 i = 0 ; i < n を 0..n と表記
稀に用いられる閉区間
従来 i = 0 ; i <= n を 0..=n と表記
このようにシンプルに従来と対応している
この2種類しかないため逆に取り違えて誤用することもない
116: 2025/09/28(日) 00:57:38.05 ID:aU9wcwp7(1/3)調 AAS
>>114
108と113は別人だから、少なくとも2人はいるな。左右対称の..が閉区間に見えるのが自然な感覚なのに、
それに反して半開区間を割り当てているのが正解だなんて言い張っている方がカルト教団だよ。
数学に固執する本当のパラノイアはJuliaの作者だな。文字列連結演算子には+を使うのが自然な感覚なのに、
数学では+は可換演算子だから不適切で、*は非可換演算子の場合もある（例：行列演算）から*を使うのが
適切と言い張っている。
117: 2025/09/28(日) 01:05:52.83 ID:IhNFMRKQ(1)調 AAS
>>115
合理的だな
118: 2025/09/28(日) 01:15:35.68 ID:aU9wcwp7(2/3)調 AAS
>>115
<は右の値を含まないことが一目瞭然だが、..はそうではなく右の値を含むようにしか見えない。
119(1): 2025/09/28(日) 01:22:45.65 ID:OpklV7ok(1)調 AAS
対称なstart:endで半開区間を示す言語も多いけどそれには文句をつけずに
なぜかstart..endだけに文句をつけているから単なるキチガイだと思う
120: 2025/09/28(日) 01:28:15.16 ID:aU9wcwp7(3/3)調 AAS
>>119
:で半開区間を表す言語なんてあったっけ?
121: 2025/09/28(日) 01:34:38.77 ID:exR0IU1B(1)調 AAS
マイクロソフトまでもがC#8.0でついに導入した範囲構文を
「start..end」と記述して半開区間を意味することにしちゃったからね
半開区間が多数派だよ
122: 2025/09/28(日) 02:06:41.24 ID:OkDUf4Ut(1)調 AAS
>>102
気持ち悪いから絡んでくんなRust信者
123(1): 2025/09/28(日) 02:22:58.32 ID:/6w9hfWi(1)調 AAS
現在メジャーに使われているプログラミング言語で調査してみた
start:endやstart..endと書いた時にどちらを意味するか？
【閉区間】Ruby
【半開区間】C# Go Python Rust
124: 2025/09/28(日) 03:25:05.02 ID:1+QqAxps(1)調 AAS
Rubyでも半開区間はstart...endと左右対称な形で書くよ
「半開区間を左右対称な形に記述するな！」と主張してる>>108は頭おかしい
125: 2025/09/28(日) 06:17:53.02 ID:riDxLC/x(1)調 AAS
彼の主張する
・閉区間はPascalと同じstart..end
・半開区間は左右非対称な記号列
を満たす言語はそもそも存在するの？
Pascal自体は半開区間が存在しないから満たさない
>>123の各言語はRubyを含めて半開区間が左右対称な記号列
126: 2025/09/28(日) 06:43:10.95 AAS
>>91
>>>90
>区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。
これすげえな
多重ループすら見たことないのか
127: 2025/09/28(日) 08:23:09.99 ID:0sdmbxgV(1)調 AAS
ここの住人もQiitaと同レベルだよな
128: 2025/09/28(日) 08:34:28.79 ID:SzcnPpn2(1)調 AAS
争いは同じレベルの者同士でしか発生しないからな
129(1): 2025/09/28(日) 13:02:57.89 ID:iPJCP/07(1/2)調 AAS
現行の言語のデザインに何も疑問を持たないのはそれだけの人
130: 2025/09/28(日) 13:46:21.84 AAS
>>129
違うデザインのものなんて無数にあるのに誰も支持しなかったことすら考えられないからお前は中卒無職ヒキコモリ脳障害なんだよ
自殺しとけ猿が
131: 2025/09/28(日) 13:49:09.56 AAS
全てのインデックスを過不足なく処理することの需要が最も大きいんだから
その用法の記述が最もシンプルになるべき
情報圧縮なんて聞いたことすら無いから登場頻度の多いものに少ないビット数を割り当てるなんて聞いたことすらないんだろう
そこで数学ガーとか言い出すのは間違いなく数学も出来ない低学歴無職
132: 2025/09/28(日) 14:09:14.21 ID:Md4hnl4x(1)調 AAS
どの言語も範囲指定は半開区間が基本だから困ってる人はいないだろ
半開区間を左右非対称な記法にしなければ閉区間と誤解する人なんていない
133: 2025/09/28(日) 15:14:07.50 AAS
左右対称とかバカしかやらない
インデックスを過不足なく処理したいのに閉区間にされたら端の重複を除外する処理が追加で必要になる
知能が存在しないからそんな妄想ができる
間違いなく中学レベルの数学の証明すらできない脳障害の妄想
バカすぎて数学が出来なくて悔しかったので
思考力の無さを誤魔化すために「数学原理主義」に立つことで自分は数学ができるんだと言い聞かせるという低学歴しぐさ
134: 2025/09/28(日) 16:40:35.56 ID:1TqmSl7N(1/2)調 AAS
急所突かれて発狂ｗ
135(1): 2025/09/28(日) 17:11:35.80 ID:AfcFEDfn(1)調 AAS
Pythonのlist[start:end]は半開区間でstartを含んでendは含まないけど
これを「閉区間と勘違いするから左右非対称なlist[start:<end]に変更しろ」と要求してるのかよwww
136: 2025/09/28(日) 17:32:21.30 ID:1TqmSl7N(2/2)調 AAS
半開区間と閉区間の両方をサポートする言語と半開区間か閉区間のどちらかしかサポートしない言語との区別がつかない>>135は馬鹿だな
137: 2025/09/28(日) 18:01:58.35 ID:fCzTTfAf(1)調 AAS
なるほど
両方サポートしていれば閉区間の指定方法が別途あるから確実に両者の区別がついて混乱しないってことか
138: 2025/09/28(日) 18:33:01.36 AAS
そんなもん使い道が無い
139(1): 2025/09/28(日) 18:33:42.56 AAS
そもそもマシンコードに区間なんて存在しないんだから
内部的に２つの条件判断に置き換えるだけ
サポートしてるかどうかなど全く無意味
140: 2025/09/28(日) 18:34:40.04 AAS
しかもいまだにAIエージェントでコーディングしてない時点でヤバすぎる
やるのはエージェントだからタイピングの手間とか見やすさとかそんなものは存在しない
仕事してない無職の妄想
141(2): 2025/09/28(日) 18:58:05.58 ID:abSkBPDh(1)調 AAS
AIにとっては左右非対称であることが重要
左右対称なら閉区間だと思い込む可能性が高い
142: 2025/09/28(日) 19:03:52.16 AAS
>>141
無職の妄想は意味ないよ
143: 2025/09/28(日) 19:04:21.97 AAS
>>141
証拠出せよ
出せないなら自殺して詫びろ
144(1): 2025/09/28(日) 19:17:29.37 ID:HeMXelkZ(1)調 AAS
そもそも人間は左右対称だと閉区間と思い込むもんなの？
そこからおかしいんじゃないの？
145: 2025/09/28(日) 19:19:06.15 AAS
>>144
思い込まない
何の証拠もない中卒の妄想
ソースが無い
146: 2025/09/28(日) 19:21:01.28 AAS
話題になり得るのはAIエージェントが取り違えしてないかどうかチェックするためのテストコードをどうやってAIエージェントに漏れなく全ての箇所で書かせるかとかだろ
人間にとっての見やすさなんて無職の自白
147: 2025/09/28(日) 19:28:03.90 AAS
区間記号を全てgrepして該当箇所をファイルに書き出して書き込み禁止にし
その該当箇所全てでテストコードを書かことを義務付けてパスしないと認めない指示にするとかだな
記号なんて全くどうでも良い
テストするんだから
148: 2025/09/28(日) 19:29:08.83 AAS
区間記号の解釈とテストがどうなっているべきかも.mdに最初に書かせて
それを守ってない行動は全てリバート
149: 2025/09/28(日) 19:38:57.62 ID:NUkjyMN+(1)調 AAS
現在メジャーに使われているプログラミング言語で調査してみた
半開区間の指定が左右対称か左右非対称か？
【左右対称】C# Go Python Ruby Rust
【左右非対称】Swift
150: 2025/09/28(日) 20:05:41.70 ID:iPJCP/07(2/2)調 AAS
>>139
> そもそもマシンコードに区間なんて存在しないんだから
> 内部的に２つの条件判断に置き換えるだけ
外部ﾘﾝｸ:godbolt.org と 外部ﾘﾝｸ:godbolt.org じゃ結構違うと思うが何言ってる?
上下前次1-新書関写板覧索設栞歴
あと 1 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.057s