Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)
https://qiita.com/
Qiita(キータ)は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。
https://internet.watch.impress.co.jp/docs/news/1025972.html
前スレ Qiita
https://mevius.5ch.net/test/read.cgi/tech/1542357242/
Qiita 2 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1658762410/
Qiita 3 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1685235361/
Qiita 4 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1705486836/
Qiita 5 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1717651046/
Qiita 6 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1739527246/
Qiita 7 - キータぞ、来たぞ、キータだぞー
2025/09/13(土) 12:24:07.83ID:mucntwOq
107デフォルトの名無しさん
2025/09/27(土) 21:12:07.66ID:PCqkgGFG >特定のCPU/GPU環境と断ってる
>C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え
記事のコードがダメのはC言語の仕様として未定義動作と規定されてることをやってるからで特定CPU関係ないよ。
>C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え
記事のコードがダメのはC言語の仕様として未定義動作と規定されてることをやってるからで特定CPU関係ないよ。
108デフォルトの名無しさん
2025/09/27(土) 21:17:11.52ID:jktxSQ82109デフォルトの名無しさん
2025/09/27(土) 21:29:49.40ID:B/IRYC2K >>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)
とてもわかりやすくなっているね。
それら現在メジャーな各言語の、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.15ID:jktxSQ82 >>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文字をケチるのは愚行。
そんなものがわかりやすいわけないだろ。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デフォルトの名無しさん
2025/09/27(土) 21:54:38.07ID:h+m11Qj8 ① 多用される半開区間を少ない記号で書けるよう .. を半開区間の記号にしました。
② Pascal以来の伝統を重視して .. を閉区間の記号にしました。
③ 閉区間の記号は数学記号に倣って左右対称であるべきなので .. を閉区間の記号にしました。
自分は、説得力を感じる度合いとしては① >= ② >>> ③ かな。③ははっきり言ってパラノイアの戯言レベルの物言いにしか思えない。
また、半開区間の記号を ..< とか ..〜 のような冗長で読みにくい記号にする前提なら、それが .. を閉区間の記号にしたくない最大の理由になるかな。Pascalのように閉区間の記号しか設けていないのなら仕方ないが、開区間と閉区間の記号を両方用意するなら、開区間の記号の方をスッキリした記号にして欲しい。Rubyの .. と... で許容範囲ギリギリくらい。
② Pascal以来の伝統を重視して .. を閉区間の記号にしました。
③ 閉区間の記号は数学記号に倣って左右対称であるべきなので .. を閉区間の記号にしました。
自分は、説得力を感じる度合いとしては① >= ② >>> ③ かな。③ははっきり言ってパラノイアの戯言レベルの物言いにしか思えない。
また、半開区間の記号を ..< とか ..〜 のような冗長で読みにくい記号にする前提なら、それが .. を閉区間の記号にしたくない最大の理由になるかな。Pascalのように閉区間の記号しか設けていないのなら仕方ないが、開区間と閉区間の記号を両方用意するなら、開区間の記号の方をスッキリした記号にして欲しい。Rubyの .. と... で許容範囲ギリギリくらい。
112デフォルトの名無しさん
2025/09/27(土) 22:08:37.36ID:jktxSQ82113デフォルトの名無しさん
2025/09/27(土) 22:45:20.51ID:fM3CYn91 > 閉区間[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
これでいうと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デフォルトの名無しさん
2025/09/27(土) 23:23:15.70ID:h+m11Qj8 このスレでパラノイアの妄執を開陳されてもなぁ。
..< とか <..< とかで「一貫してるぞ、わーい」って喜べるの貴方くらいだよ。
..< とか <..< とかで「一貫してるぞ、わーい」って喜べるの貴方くらいだよ。
115デフォルトの名無しさん
2025/09/27(土) 23:40:53.38ID:xS2lIG/M Rustは非常にシンプルで
最も多用されて使いやすい半開区間
従来 i = 0 ; i < n を 0..n と表記
稀に用いられる閉区間
従来 i = 0 ; i <= n を 0..=n と表記
このようにシンプルに従来と対応している
この2種類しかないため逆に取り違えて誤用することもない
最も多用されて使いやすい半開区間
従来 i = 0 ; i < n を 0..n と表記
稀に用いられる閉区間
従来 i = 0 ; i <= n を 0..=n と表記
このようにシンプルに従来と対応している
この2種類しかないため逆に取り違えて誤用することもない
116デフォルトの名無しさん
2025/09/28(日) 00:57:38.05ID:aU9wcwp7 >>114
108と113は別人だから、少なくとも2人はいるな。左右対称の..が閉区間に見えるのが自然な感覚なのに、
それに反して半開区間を割り当てているのが正解だなんて言い張っている方がカルト教団だよ。
数学に固執する本当のパラノイアはJuliaの作者だな。文字列連結演算子には+を使うのが自然な感覚なのに、
数学では+は可換演算子だから不適切で、*は非可換演算子の場合もある(例:行列演算)から*を使うのが
適切と言い張っている。
108と113は別人だから、少なくとも2人はいるな。左右対称の..が閉区間に見えるのが自然な感覚なのに、
それに反して半開区間を割り当てているのが正解だなんて言い張っている方がカルト教団だよ。
数学に固執する本当のパラノイアはJuliaの作者だな。文字列連結演算子には+を使うのが自然な感覚なのに、
数学では+は可換演算子だから不適切で、*は非可換演算子の場合もある(例:行列演算)から*を使うのが
適切と言い張っている。
117デフォルトの名無しさん
2025/09/28(日) 01:05:52.83ID:IhNFMRKQ >>115
合理的だな
合理的だな
118デフォルトの名無しさん
2025/09/28(日) 01:15:35.68ID:aU9wcwp7 >>115
<は右の値を含まないことが一目瞭然だが、..はそうではなく右の値を含むようにしか見えない。
<は右の値を含まないことが一目瞭然だが、..はそうではなく右の値を含むようにしか見えない。
119デフォルトの名無しさん
2025/09/28(日) 01:22:45.65ID:OpklV7ok 対称なstart:endで半開区間を示す言語も多いけどそれには文句をつけずに
なぜかstart..endだけに文句をつけているから単なるキチガイだと思う
なぜかstart..endだけに文句をつけているから単なるキチガイだと思う
120デフォルトの名無しさん
2025/09/28(日) 01:28:15.16ID:aU9wcwp7 >>119
:で半開区間を表す言語なんてあったっけ?
:で半開区間を表す言語なんてあったっけ?
121デフォルトの名無しさん
2025/09/28(日) 01:34:38.77ID:exR0IU1B マイクロソフトまでもがC#8.0でついに導入した範囲構文を
「start..end」と記述して半開区間を意味することにしちゃったからね
半開区間が多数派だよ
「start..end」と記述して半開区間を意味することにしちゃったからね
半開区間が多数派だよ
122デフォルトの名無しさん
2025/09/28(日) 02:06:41.24ID:OkDUf4Ut >>102
気持ち悪いから絡んでくんなRust信者
気持ち悪いから絡んでくんなRust信者
123デフォルトの名無しさん
2025/09/28(日) 02:22:58.32ID:/6w9hfWi 現在メジャーに使われているプログラミング言語で調査してみた
start:endやstart..endと書いた時にどちらを意味するか?
【閉区間】Ruby
【半開区間】C# Go Python Rust
start:endやstart..endと書いた時にどちらを意味するか?
【閉区間】Ruby
【半開区間】C# Go Python Rust
124デフォルトの名無しさん
2025/09/28(日) 03:25:05.02ID:1+QqAxps Rubyでも半開区間はstart...endと左右対称な形で書くよ
「半開区間を左右対称な形に記述するな!」と主張してる>>108は頭おかしい
「半開区間を左右対称な形に記述するな!」と主張してる>>108は頭おかしい
125デフォルトの名無しさん
2025/09/28(日) 06:17:53.02ID:riDxLC/x 彼の主張する
・閉区間はPascalと同じstart..end
・半開区間は左右非対称な記号列
を満たす言語はそもそも存在するの?
Pascal自体は半開区間が存在しないから満たさない
>>123の各言語はRubyを含めて半開区間が左右対称な記号列
・閉区間はPascalと同じstart..end
・半開区間は左右非対称な記号列
を満たす言語はそもそも存在するの?
Pascal自体は半開区間が存在しないから満たさない
>>123の各言語はRubyを含めて半開区間が左右対称な記号列
126デフォルトの名無しさん
2025/09/28(日) 06:43:10.95127デフォルトの名無しさん
2025/09/28(日) 08:23:09.99ID:0sdmbxgV ここの住人もQiitaと同レベルだよな
128デフォルトの名無しさん
2025/09/28(日) 08:34:28.79ID:SzcnPpn2 争いは同じレベルの者同士でしか発生しないからな
129デフォルトの名無しさん
2025/09/28(日) 13:02:57.89ID:iPJCP/07 現行の言語のデザインに何も疑問を持たないのはそれだけの人
130デフォルトの名無しさん
2025/09/28(日) 13:46:21.84131デフォルトの名無しさん
2025/09/28(日) 13:49:09.56 全てのインデックスを過不足なく処理することの需要が最も大きいんだから
その用法の記述が最もシンプルになるべき
情報圧縮なんて聞いたことすら無いから登場頻度の多いものに少ないビット数を割り当てるなんて聞いたことすらないんだろう
そこで数学ガーとか言い出すのは間違いなく数学も出来ない低学歴無職
その用法の記述が最もシンプルになるべき
情報圧縮なんて聞いたことすら無いから登場頻度の多いものに少ないビット数を割り当てるなんて聞いたことすらないんだろう
そこで数学ガーとか言い出すのは間違いなく数学も出来ない低学歴無職
132デフォルトの名無しさん
2025/09/28(日) 14:09:14.21ID:Md4hnl4x どの言語も範囲指定は半開区間が基本だから困ってる人はいないだろ
半開区間を左右非対称な記法にしなければ閉区間と誤解する人なんていない
半開区間を左右非対称な記法にしなければ閉区間と誤解する人なんていない
133デフォルトの名無しさん
2025/09/28(日) 15:14:07.50 左右対称とかバカしかやらない
インデックスを過不足なく処理したいのに閉区間にされたら端の重複を除外する処理が追加で必要になる
知能が存在しないからそんな妄想ができる
間違いなく中学レベルの数学の証明すらできない脳障害の妄想
バカすぎて数学が出来なくて悔しかったので
思考力の無さを誤魔化すために「数学原理主義」に立つことで自分は数学ができるんだと言い聞かせるという低学歴しぐさ
インデックスを過不足なく処理したいのに閉区間にされたら端の重複を除外する処理が追加で必要になる
知能が存在しないからそんな妄想ができる
間違いなく中学レベルの数学の証明すらできない脳障害の妄想
バカすぎて数学が出来なくて悔しかったので
思考力の無さを誤魔化すために「数学原理主義」に立つことで自分は数学ができるんだと言い聞かせるという低学歴しぐさ
134デフォルトの名無しさん
2025/09/28(日) 16:40:35.56ID:1TqmSl7N 急所突かれて発狂w
135デフォルトの名無しさん
2025/09/28(日) 17:11:35.80ID:AfcFEDfn Pythonのlist[start:end]は半開区間でstartを含んでendは含まないけど
これを「閉区間と勘違いするから左右非対称なlist[start:<end]に変更しろ」と要求してるのかよwww
これを「閉区間と勘違いするから左右非対称なlist[start:<end]に変更しろ」と要求してるのかよwww
136デフォルトの名無しさん
2025/09/28(日) 17:32:21.30ID:1TqmSl7N 半開区間と閉区間の両方をサポートする言語と半開区間か閉区間のどちらかしかサポートしない言語との区別がつかない>>135は馬鹿だな
137デフォルトの名無しさん
2025/09/28(日) 18:01:58.35ID:fCzTTfAf なるほど
両方サポートしていれば閉区間の指定方法が別途あるから確実に両者の区別がついて混乱しないってことか
両方サポートしていれば閉区間の指定方法が別途あるから確実に両者の区別がついて混乱しないってことか
138デフォルトの名無しさん
2025/09/28(日) 18:33:01.36 そんなもん使い道が無い
139デフォルトの名無しさん
2025/09/28(日) 18:33:42.56 そもそもマシンコードに区間なんて存在しないんだから
内部的に2つの条件判断に置き換えるだけ
サポートしてるかどうかなど全く無意味
内部的に2つの条件判断に置き換えるだけ
サポートしてるかどうかなど全く無意味
140デフォルトの名無しさん
2025/09/28(日) 18:34:40.04 しかもいまだにAIエージェントでコーディングしてない時点でヤバすぎる
やるのはエージェントだからタイピングの手間とか見やすさとかそんなものは存在しない
仕事してない無職の妄想
やるのはエージェントだからタイピングの手間とか見やすさとかそんなものは存在しない
仕事してない無職の妄想
141デフォルトの名無しさん
2025/09/28(日) 18:58:05.58ID:abSkBPDh AIにとっては左右非対称であることが重要
左右対称なら閉区間だと思い込む可能性が高い
左右対称なら閉区間だと思い込む可能性が高い
142デフォルトの名無しさん
2025/09/28(日) 19:03:52.16 >>141
無職の妄想は意味ないよ
無職の妄想は意味ないよ
143デフォルトの名無しさん
2025/09/28(日) 19:04:21.97144デフォルトの名無しさん
2025/09/28(日) 19:17:29.37ID:HeMXelkZ そもそも人間は左右対称だと閉区間と思い込むもんなの?
そこからおかしいんじゃないの?
そこからおかしいんじゃないの?
145デフォルトの名無しさん
2025/09/28(日) 19:19:06.15146デフォルトの名無しさん
2025/09/28(日) 19:21:01.28 話題になり得るのはAIエージェントが取り違えしてないかどうかチェックするためのテストコードをどうやってAIエージェントに漏れなく全ての箇所で書かせるかとかだろ
人間にとっての見やすさなんて無職の自白
人間にとっての見やすさなんて無職の自白
147デフォルトの名無しさん
2025/09/28(日) 19:28:03.90 区間記号を全てgrepして該当箇所をファイルに書き出して書き込み禁止にし
その該当箇所全てでテストコードを書かことを義務付けてパスしないと認めない指示にするとかだな
記号なんて全くどうでも良い
テストするんだから
その該当箇所全てでテストコードを書かことを義務付けてパスしないと認めない指示にするとかだな
記号なんて全くどうでも良い
テストするんだから
148デフォルトの名無しさん
2025/09/28(日) 19:29:08.83 区間記号の解釈とテストがどうなっているべきかも.mdに最初に書かせて
それを守ってない行動は全てリバート
それを守ってない行動は全てリバート
149デフォルトの名無しさん
2025/09/28(日) 19:38:57.62ID:NUkjyMN+ 現在メジャーに使われているプログラミング言語で調査してみた
半開区間の指定が左右対称か左右非対称か?
【左右対称】C# Go Python Ruby Rust
【左右非対称】Swift
半開区間の指定が左右対称か左右非対称か?
【左右対称】C# Go Python Ruby Rust
【左右非対称】Swift
150デフォルトの名無しさん
2025/09/28(日) 20:05:41.70ID:iPJCP/07 >>139
> そもそもマシンコードに区間なんて存在しないんだから
> 内部的に2つの条件判断に置き換えるだけ
https://godbolt.org/z/q6T916rjW と https://godbolt.org/z/KvxEv7dsq じゃ結構違うと思うが何言ってる?
> そもそもマシンコードに区間なんて存在しないんだから
> 内部的に2つの条件判断に置き換えるだけ
https://godbolt.org/z/q6T916rjW と https://godbolt.org/z/KvxEv7dsq じゃ結構違うと思うが何言ってる?
151デフォルトの名無しさん
2025/09/28(日) 20:16:56.42152デフォルトの名無しさん
2025/09/28(日) 20:25:27.74ID:iPJCP/07 >>151
ちょっと何言いたいんだか分からんね。
ちょっと何言いたいんだか分からんね。
153デフォルトの名無しさん
2025/09/28(日) 20:27:54.00 >>152
アセンブラ書けねえのか無知
アセンブラ書けねえのか無知
154デフォルトの名無しさん
2025/09/28(日) 20:28:29.22155デフォルトの名無しさん
2025/09/28(日) 20:29:19.56156デフォルトの名無しさん
2025/09/28(日) 20:33:56.40ID:iPJCP/07 > 最終的にどんなマシンコードになるか知らないバカが妄想しても意味ねーから
スマホで見て発狂してる可能性もあるかな?
スマホで見て発狂してる可能性もあるかな?
157デフォルトの名無しさん
2025/09/28(日) 20:37:44.61158デフォルトの名無しさん
2025/09/28(日) 20:48:48.21ID:iPJCP/07 > 最適化レベルすら指定してない猿
指定してる -Copt-level=2 が最適化指示とわからん人かな?
指定してる -Copt-level=2 が最適化指示とわからん人かな?
159デフォルトの名無しさん
2025/09/28(日) 20:59:03.90ID:67OEPeOQ AIって想像以上にアホだぞ
160デフォルトの名無しさん
2025/09/28(日) 21:12:11.28ID:aU9wcwp7 >>124
Rubyは閉区間と半開区間の両方を提供したことと、閉区間に左右対称な..を採用したことでは
賢明だったが、半開区間に左右対称な...を採用したのは惜しい誤りだったな。..とも判別しづらいし。
..<か..~にすべきだった。
>>125
>>66にも書いたように、Swiftでは閉区間は...で左右対称、半開区間は..<で左右非対称だよ。
閉区間はPascalの..より.が1つ多い...だが、左右対称という点では共通する。
増分も指定できるように拡張することを見越すと、半開区間には..<より..~の方が適している。
開始値..増分..<終了値だと増分が負のとき変な感じがするが、開始値..増分..~終了値ならば
問題ないから。
もっともSwiftでは増分指定では記号を使わない。stride(from: 開始値, through: 終了値, by: 増分) の
ように省略不可の名前付き引数を書かせる。そして、名前付き引数だから順不同ということもなく、
この順でしか受け付けない。このようなガチガチの書式で固めたのもバグを防ぐための用心だろう。
Fortran, Juliaでは開始値:終了値:増分だがMATALAB, Octave, Scilabでは開始値:増分:終了値で
順序が異なるため、混同による書き間違えの恐れがあるから。
Rubyは閉区間と半開区間の両方を提供したことと、閉区間に左右対称な..を採用したことでは
賢明だったが、半開区間に左右対称な...を採用したのは惜しい誤りだったな。..とも判別しづらいし。
..<か..~にすべきだった。
>>125
>>66にも書いたように、Swiftでは閉区間は...で左右対称、半開区間は..<で左右非対称だよ。
閉区間はPascalの..より.が1つ多い...だが、左右対称という点では共通する。
増分も指定できるように拡張することを見越すと、半開区間には..<より..~の方が適している。
開始値..増分..<終了値だと増分が負のとき変な感じがするが、開始値..増分..~終了値ならば
問題ないから。
もっともSwiftでは増分指定では記号を使わない。stride(from: 開始値, through: 終了値, by: 増分) の
ように省略不可の名前付き引数を書かせる。そして、名前付き引数だから順不同ということもなく、
この順でしか受け付けない。このようなガチガチの書式で固めたのもバグを防ぐための用心だろう。
Fortran, Juliaでは開始値:終了値:増分だがMATALAB, Octave, Scilabでは開始値:増分:終了値で
順序が異なるため、混同による書き間違えの恐れがあるから。
161デフォルトの名無しさん
2025/09/28(日) 21:13:50.83ID:aU9wcwp7 >>131
>>116に挙げたJuliaの作者じゃないから、数学に合わせること自体に固執しているわけではない。
左右対称な..が閉区間を表すのが自然な感覚で、それに反するのはバグの元だからやめるべきだと
いうのが根源的な理由で、数学はそれに反していない例として挙げたに過ぎない。
人間は機械ではないから見た目に惑わされやすい。機械だけが相手なら半開区間をi!jで表せば
効率が最も良いし、多くの言語では破壊的変更も文法的に不要で好都合なはずだが、人間の
感覚では!は半開区間とは容易に結びつかない(:の変形と見なせば結びつかなくもないが)し、
|とも判別しづらいから不適当。
屁理屈を捏ねて自然な感覚に反することを強制するのは、ギークの村社会のキモい悪習としか
言いようがない。プログラム言語の記法の選定はUI設計の一種なのに、不自然で間違えやすい
記号を採用するのは工学的センスが絶望的にない。UIは美的にも心地良いことに越したことはなく、
その点でも見苦しい略語を多用するRustは落第だな。そもそも名前からして汚らしい。
>>144
基本ラテン文字の大文字全体を'A'..'Z'で表すのが素直な感覚(EBCDICのような化石はこの際
無視して良い)で、'Y'までしか含まないと言い張るのは無理がある。'A'..='Z'は冗長だし、
'A'..'['では何を意図しているかすぐには分からない人が多いだろう。
>>116に挙げたJuliaの作者じゃないから、数学に合わせること自体に固執しているわけではない。
左右対称な..が閉区間を表すのが自然な感覚で、それに反するのはバグの元だからやめるべきだと
いうのが根源的な理由で、数学はそれに反していない例として挙げたに過ぎない。
人間は機械ではないから見た目に惑わされやすい。機械だけが相手なら半開区間をi!jで表せば
効率が最も良いし、多くの言語では破壊的変更も文法的に不要で好都合なはずだが、人間の
感覚では!は半開区間とは容易に結びつかない(:の変形と見なせば結びつかなくもないが)し、
|とも判別しづらいから不適当。
屁理屈を捏ねて自然な感覚に反することを強制するのは、ギークの村社会のキモい悪習としか
言いようがない。プログラム言語の記法の選定はUI設計の一種なのに、不自然で間違えやすい
記号を採用するのは工学的センスが絶望的にない。UIは美的にも心地良いことに越したことはなく、
その点でも見苦しい略語を多用するRustは落第だな。そもそも名前からして汚らしい。
>>144
基本ラテン文字の大文字全体を'A'..'Z'で表すのが素直な感覚(EBCDICのような化石はこの際
無視して良い)で、'Y'までしか含まないと言い張るのは無理がある。'A'..='Z'は冗長だし、
'A'..'['では何を意図しているかすぐには分からない人が多いだろう。
162デフォルトの名無しさん
2025/09/28(日) 21:25:20.44ID:YRR4qqFp Rustのイテレータがとてもわかりやすい
【C】i = 0 ; i < n; i++
【Rust】0..n
と
【C】i = 0 ; i <= n; i++
【Rust】0..=n
対応している
【C】i = 0 ; i < n; i++
【Rust】0..n
と
【C】i = 0 ; i <= n; i++
【Rust】0..=n
対応している
163デフォルトの名無しさん
2025/09/28(日) 21:32:15.76 >>158
書いてないぞ
書いてないぞ
164デフォルトの名無しさん
2025/09/28(日) 21:38:57.07165デフォルトの名無しさん
2025/09/28(日) 21:43:13.72166デフォルトの名無しさん
2025/09/28(日) 22:05:51.43ID:aU9wcwp7 >>164
正直に白状しろ。心当たりが全くなくはないはずだ。
C++ STLの.begin()と.end()の組の.end()を書くときにも、もやもやする感覚が常に伴うな。
『リーダブルコード』に、
プログラミングの命名規約では、包含/排他的範囲にbeginとendを使うことが多い。
でも、endは少しあいまいだ。例えば、「本の終盤(the end of the book)を読んでいる」の
「end」は包含的だ。残念ながら英語には「ちょうど最後の値を超えたところ」を意味する簡潔な
言葉がない。
と述べられている通り。簡潔な言葉がないなら作れば良かったと思う。例えば、endの次(next)だから
nendとか。無闇に造語すべきではないが、どうしても必要なら作れば良い。bitは成功例だろう。
とは言え、複数の本を本棚に並べ右端の横にブックエンドを置いたとき、.end()は本そのものではなく
ブックエンドだと考えれば、.end()はまあ納得できるから..ほど悪くはなく許容できる。
>>165
誤記予防という機能性を犠牲にしてたった1文字をケチる愚行。第一、閉区間より半開区間の方が頻繁に
使われるという主張も怪しい。作るプログラムによって異なるだろ。
正直に白状しろ。心当たりが全くなくはないはずだ。
C++ STLの.begin()と.end()の組の.end()を書くときにも、もやもやする感覚が常に伴うな。
『リーダブルコード』に、
プログラミングの命名規約では、包含/排他的範囲にbeginとendを使うことが多い。
でも、endは少しあいまいだ。例えば、「本の終盤(the end of the book)を読んでいる」の
「end」は包含的だ。残念ながら英語には「ちょうど最後の値を超えたところ」を意味する簡潔な
言葉がない。
と述べられている通り。簡潔な言葉がないなら作れば良かったと思う。例えば、endの次(next)だから
nendとか。無闇に造語すべきではないが、どうしても必要なら作れば良い。bitは成功例だろう。
とは言え、複数の本を本棚に並べ右端の横にブックエンドを置いたとき、.end()は本そのものではなく
ブックエンドだと考えれば、.end()はまあ納得できるから..ほど悪くはなく許容できる。
>>165
誤記予防という機能性を犠牲にしてたった1文字をケチる愚行。第一、閉区間より半開区間の方が頻繁に
使われるという主張も怪しい。作るプログラムによって異なるだろ。
167デフォルトの名無しさん
2025/09/28(日) 22:07:15.34168デフォルトの名無しさん
2025/09/28(日) 22:08:16.70169デフォルトの名無しさん
2025/09/28(日) 22:11:06.36ID:5mXw367y >>162
従来との対応関係のあることが最も重要なのでそれで正しい
従来との対応関係のあることが最も重要なのでそれで正しい
170デフォルトの名無しさん
2025/09/28(日) 22:13:10.39171デフォルトの名無しさん
2025/09/28(日) 22:15:00.74ID:aU9wcwp7 >>167
低学歴ではないが、低学歴という煽りもここでは意味がないね。プログラム言語なんて小学生でも
分かる程度のものでしかないし、一般的感覚も自然言語と高校までの数学によって形成されるものだから。
そこから乖離した屁理屈をあれこれほざいても、ギークのキモい戯言でしかない。
低学歴ではないが、低学歴という煽りもここでは意味がないね。プログラム言語なんて小学生でも
分かる程度のものでしかないし、一般的感覚も自然言語と高校までの数学によって形成されるものだから。
そこから乖離した屁理屈をあれこれほざいても、ギークのキモい戯言でしかない。
172デフォルトの名無しさん
2025/09/28(日) 22:18:09.06 >>171
ソース出せない妄想と
ソース出せない妄想と
173デフォルトの名無しさん
2025/09/28(日) 22:18:52.64174デフォルトの名無しさん
2025/09/28(日) 22:23:17.24ID:iPJCP/07175デフォルトの名無しさん
2025/09/28(日) 22:26:42.41ID:iPJCP/07 いまこのスレで発狂してるやつ見てるとQiitaでアカウントBANされたコイツ思い出すんだよなあ。
https://web.archive.org/web/20221220153804/https://qiita.com/ashworth/items/a35270d88ac52116ef7d
> はい、私が勘違いしてました。
> 途中で、
>
> スクリーンショット 2022-12-19 184235.png
>
> みたいな突っ込みがあって、やっと問題文をちゃんと読み直して『あれ?』となったわけですが、
>
> 自分、基本的にTwitterでの間違いは死んでも認めない主義なので、そのまま押し切る事にしました。
>
> Twitterとかのネットは所詮遊び場なので「バトルしようぜ、Tweetバトル!俺が勝ったらテメェは俺以下だぁー!!」みたいなノリで強引に押し切ろうとしました。
>
> で、まぁ、惨敗したわけですけどねw
https://web.archive.org/web/20221220153804/https://qiita.com/ashworth/items/a35270d88ac52116ef7d
> はい、私が勘違いしてました。
> 途中で、
>
> スクリーンショット 2022-12-19 184235.png
>
> みたいな突っ込みがあって、やっと問題文をちゃんと読み直して『あれ?』となったわけですが、
>
> 自分、基本的にTwitterでの間違いは死んでも認めない主義なので、そのまま押し切る事にしました。
>
> Twitterとかのネットは所詮遊び場なので「バトルしようぜ、Tweetバトル!俺が勝ったらテメェは俺以下だぁー!!」みたいなノリで強引に押し切ろうとしました。
>
> で、まぁ、惨敗したわけですけどねw
176デフォルトの名無しさん
2025/09/28(日) 22:27:15.68ID:jJ7lr+aR 以下の性質の良さの違いのため
プログラミングでは半開区間が多用されている
半開区間 (性質が良い)
・start~endの長さはend-start
・startから始まる長さlenの区間はstart~(start+len)
・startから始まる長さ0の区間はstart~startと表せてそのまま自然に扱える
・途中middleでstart~middleとmiddle~endの二つに分割できる
閉区間 (性質が悪い)
・start~endの長さはend-start+1
・startから始まる長さlenの区間はstart~(start+len-1)
・startから始まる長さ0の区間はstart~(start-1)になって破綻
・途中middleでstart~middleとmiddle~endの二つに分割できない
start~middleと(middle+1)~endか
start~(middle-1)とmiddle~endになる
プログラミングでは半開区間が多用されている
半開区間 (性質が良い)
・start~endの長さはend-start
・startから始まる長さlenの区間はstart~(start+len)
・startから始まる長さ0の区間はstart~startと表せてそのまま自然に扱える
・途中middleでstart~middleとmiddle~endの二つに分割できる
閉区間 (性質が悪い)
・start~endの長さはend-start+1
・startから始まる長さlenの区間はstart~(start+len-1)
・startから始まる長さ0の区間はstart~(start-1)になって破綻
・途中middleでstart~middleとmiddle~endの二つに分割できない
start~middleと(middle+1)~endか
start~(middle-1)とmiddle~endになる
177デフォルトの名無しさん
2025/09/28(日) 22:27:24.30ID:aU9wcwp7179デフォルトの名無しさん
2025/09/28(日) 22:38:40.96ID:jJ7lr+aR 区間指定の文法を持つ最近のメジャーなプログラミング言語では半開区間を簡単に表記できるようになっている
例えば
GoやPythonなどでは list[start:end]
C#やRustなどでは list[start..end]
いずれもendを含まない半開区間を意味している
例えば
GoやPythonなどでは list[start:end]
C#やRustなどでは list[start..end]
いずれもendを含まない半開区間を意味している
180デフォルトの名無しさん
2025/09/28(日) 22:46:12.82ID:aU9wcwp7181デフォルトの名無しさん
2025/09/28(日) 22:47:22.28182デフォルトの名無しさん
2025/09/28(日) 22:47:41.83183デフォルトの名無しさん
2025/09/28(日) 22:49:02.93184デフォルトの名無しさん
2025/09/28(日) 23:01:12.25ID:aU9wcwp7185デフォルトの名無しさん
2025/09/28(日) 23:01:37.54 >>184
これが無職
これが無職
186デフォルトの名無しさん
2025/09/28(日) 23:25:09.36ID:jJ7lr+aR >>183
初心者は仕方ないとしてもプログラミング歴のある人には必須な知識だと思う
初心者は仕方ないとしてもプログラミング歴のある人には必須な知識だと思う
187デフォルトの名無しさん
2025/09/28(日) 23:34:39.97ID:SbwCraTd ここプログラム技術板で閉区間が自然だと主張して暴れてるやつはどこから来たお客さんなんだろう
188デフォルトの名無しさん
2025/09/28(日) 23:48:23.78ID:aU9wcwp7 >>187
閉区間が自然だとは全く主張していないぞ。
・閉区間で書くのが便利な場合も半開区間で書くのが便利な場合もあるので、両方の書き方を
提供するのが良い(勿論、前者の場合には閉区間が自然ということになるが)
・閉区間には左右対称、半開区間には左右非対称の記号を割り当てるのが自然で、バグを
生みにくい
と主張しているだけ。
閉区間が自然だとは全く主張していないぞ。
・閉区間で書くのが便利な場合も半開区間で書くのが便利な場合もあるので、両方の書き方を
提供するのが良い(勿論、前者の場合には閉区間が自然ということになるが)
・閉区間には左右対称、半開区間には左右非対称の記号を割り当てるのが自然で、バグを
生みにくい
と主張しているだけ。
189デフォルトの名無しさん
2025/09/28(日) 23:54:41.82ID:jJ7lr+aR 現実のメジャーなプログラミング言語では>>179のように半開区間を簡潔に記述できることを重視している
190デフォルトの名無しさん
2025/09/29(月) 00:05:25.27191デフォルトの名無しさん
2025/09/29(月) 00:05:49.17 >>188
こういうバカは無職なのが自然
こういうバカは無職なのが自然
192デフォルトの名無しさん
2025/09/29(月) 03:12:26.72ID:KaR4fBa3 >>188
func main(){
var a = [5]string{"a","b","c","d","e"}
fmt.Println(a[0]) // a
fmt.Println(a[1]) // b
fmt.Println(a[1:3]) // [b c]
}
Go言語は半開区間のみ
> 両方の書き方を提供するのが良い
半開区間のみを提供するのが良い
2つの書き方を提供するのはバグを生みやすい
あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名
func main(){
var a = [5]string{"a","b","c","d","e"}
fmt.Println(a[0]) // a
fmt.Println(a[1]) // b
fmt.Println(a[1:3]) // [b c]
}
Go言語は半開区間のみ
> 両方の書き方を提供するのが良い
半開区間のみを提供するのが良い
2つの書き方を提供するのはバグを生みやすい
あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名
193デフォルトの名無しさん
2025/09/29(月) 03:23:08.08ID:Lm5HPMDj >>192
横からだけど
Goは言語機能が非常に弱くて
その半開区間の指定も部分フライス指定にしか使えない
イテレータとして機能しない
(switchやmatchなどの)パターンマッチングにも使えない
横からだけど
Goは言語機能が非常に弱くて
その半開区間の指定も部分フライス指定にしか使えない
イテレータとして機能しない
(switchやmatchなどの)パターンマッチングにも使えない
194デフォルトの名無しさん
2025/09/29(月) 07:48:42.16ID:kekj+dde >>192
>あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名
TypeScriptコンパイラのことなら
Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#
という記事にまとめられているが
>半開区間のみを提供するのが良い
>2つの書き方を提供するのはバグを生みやすい
なんて理由は挙げられてないね。
>あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名
TypeScriptコンパイラのことなら
Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#
という記事にまとめられているが
>半開区間のみを提供するのが良い
>2つの書き方を提供するのはバグを生みやすい
なんて理由は挙げられてないね。
196デフォルトの名無しさん
2025/09/30(火) 00:17:04.81ID:jvKDz5J9 閉区間と半開区間のどちらが優れているということは誰も言ってないのに一人発狂してる人がいる感じ
197デフォルトの名無しさん
2025/09/30(火) 01:59:55.11ID:4wPfeVv9 閉区間より半開区間が優れている
そのため半開区間を短い記述で指定できる文法を用意している言語が多い
短い記述の結果として半開区間が左右対称の記述になっているが誰も気にすることはない
半開区間の記述は左右非対称であるべきだとこだわっているキチガイは一人だけ
そのため半開区間を短い記述で指定できる文法を用意している言語が多い
短い記述の結果として半開区間が左右対称の記述になっているが誰も気にすることはない
半開区間の記述は左右非対称であるべきだとこだわっているキチガイは一人だけ
198デフォルトの名無しさん
2025/09/30(火) 02:52:38.16 無職の妄想に価値はない
199デフォルトの名無しさん
2025/09/30(火) 08:25:04.59ID:EJn4wwZL グレゴリオ暦のうるう年判定に延々とおかしなイチャモンつけてたashworthまんまだなw
200デフォルトの名無しさん
2025/09/30(火) 10:36:18.87ID:hvi0j7l5 そもそも自転はずれるからな
201デフォルトの名無しさん
2025/09/30(火) 11:06:24.13ID:EJn4wwZL いまはこのルールでやりましょうというグレゴリオ暦を分かってないw
202デフォルトの名無しさん
2025/09/30(火) 12:34:48.41ID:dVe563is グレゴリオ暦のうるう年の判定ルール
・西暦年が4で割り切れる年はうるう年となる
・ただし、西暦年が100で割り切れる年はうるう年としない
・さらに、西暦年が400で割り切れる年は例外的にうるう年とする
・西暦年が4で割り切れる年はうるう年となる
・ただし、西暦年が100で割り切れる年はうるう年としない
・さらに、西暦年が400で割り切れる年は例外的にうるう年とする
203デフォルトの名無しさん
2025/09/30(火) 12:39:42.96 低学歴がなぜ低学歴なのかよくわかる
204デフォルトの名無しさん
2025/09/30(火) 12:40:27.16205デフォルトの名無しさん
2025/09/30(火) 12:40:59.11 そういうゴミクズを雇ったら終わりなので学歴システムがある
人間判定試験
猿を雇わないようにするための仕組み
人間判定試験
猿を雇わないようにするための仕組み
206デフォルトの名無しさん
2025/09/30(火) 23:54:22.10ID:gehVEPsnレスを投稿する
