Qiita 7 - キータぞ、来たぞ、キータだぞー

**デフォルトの名無しさん** · 2025/09/28(日) 02:22:58.32

現在メジャーに使われているプログラミング言語で調査してみた
start:endやstart..endと書いた時にどちらを意味するか？
【閉区間】Ruby
【半開区間】C# Go Python Rust

**デフォルトの名無しさん** · 2025/09/28(日) 03:25:05.02

Rubyでも半開区間はstart...endと左右対称な形で書くよ
「半開区間を左右対称な形に記述するな！」と主張してる>>108は頭おかしい

**デフォルトの名無しさん** · 2025/09/28(日) 06:17:53.02

彼の主張する
・閉区間はPascalと同じstart..end
・半開区間は左右非対称な記号列
を満たす言語はそもそも存在するの？

Pascal自体は半開区間が存在しないから満たさない
>>123の各言語はRubyを含めて半開区間が左右対称な記号列

**デフォルトの名無しさん** · 2025/09/28(日) 06:43:10.95

>>91
>>>90
>区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。

これすげえな
多重ループすら見たことないのか

**デフォルトの名無しさん** · 2025/09/28(日) 08:23:09.99

ここの住人もQiitaと同レベルだよな

**デフォルトの名無しさん** · 2025/09/28(日) 08:34:28.79

争いは同じレベルの者同士でしか発生しないからな

**デフォルトの名無しさん** · 2025/09/28(日) 13:02:57.89

現行の言語のデザインに何も疑問を持たないのはそれだけの人

**デフォルトの名無しさん** · 2025/09/28(日) 13:46:21.84

>>129
違うデザインのものなんて無数にあるのに誰も支持しなかったことすら考えられないからお前は中卒無職ヒキコモリ脳障害なんだよ
自殺しとけ猿が

**デフォルトの名無しさん** · 2025/09/28(日) 13:49:09.56

全てのインデックスを過不足なく処理することの需要が最も大きいんだから
その用法の記述が最もシンプルになるべき
情報圧縮なんて聞いたことすら無いから登場頻度の多いものに少ないビット数を割り当てるなんて聞いたことすらないんだろう
そこで数学ガーとか言い出すのは間違いなく数学も出来ない低学歴無職

**デフォルトの名無しさん** · 2025/09/28(日) 14:09:14.21

どの言語も範囲指定は半開区間が基本だから困ってる人はいないだろ
半開区間を左右非対称な記法にしなければ閉区間と誤解する人なんていない

**デフォルトの名無しさん** · 2025/09/28(日) 15:14:07.50

左右対称とかバカしかやらない
インデックスを過不足なく処理したいのに閉区間にされたら端の重複を除外する処理が追加で必要になる
知能が存在しないからそんな妄想ができる
間違いなく中学レベルの数学の証明すらできない脳障害の妄想
バカすぎて数学が出来なくて悔しかったので
思考力の無さを誤魔化すために「数学原理主義」に立つことで自分は数学ができるんだと言い聞かせるという低学歴しぐさ

**デフォルトの名無しさん** · 2025/09/28(日) 16:40:35.56

急所突かれて発狂ｗ

**デフォルトの名無しさん** · 2025/09/28(日) 17:11:35.80

Pythonのlist[start:end]は半開区間でstartを含んでendは含まないけど
これを「閉区間と勘違いするから左右非対称なlist[start:<end]に変更しろ」と要求してるのかよwww

**デフォルトの名無しさん** · 2025/09/28(日) 17:32:21.30

半開区間と閉区間の両方をサポートする言語と半開区間か閉区間のどちらかしかサポートしない言語との区別がつかない>>135は馬鹿だな

**デフォルトの名無しさん** · 2025/09/28(日) 18:01:58.35

なるほど
両方サポートしていれば閉区間の指定方法が別途あるから確実に両者の区別がついて混乱しないってことか

**デフォルトの名無しさん** · 2025/09/28(日) 18:33:01.36

そんなもん使い道が無い

**デフォルトの名無しさん** · 2025/09/28(日) 18:33:42.56

そもそもマシンコードに区間なんて存在しないんだから
内部的に２つの条件判断に置き換えるだけ
サポートしてるかどうかなど全く無意味

**デフォルトの名無しさん** · 2025/09/28(日) 18:34:40.04

しかもいまだにAIエージェントでコーディングしてない時点でヤバすぎる
やるのはエージェントだからタイピングの手間とか見やすさとかそんなものは存在しない
仕事してない無職の妄想

**デフォルトの名無しさん** · 2025/09/28(日) 18:58:05.58

AIにとっては左右非対称であることが重要
左右対称なら閉区間だと思い込む可能性が高い

**デフォルトの名無しさん** · 2025/09/28(日) 19:03:52.16

>>141
無職の妄想は意味ないよ

**デフォルトの名無しさん** · 2025/09/28(日) 19:04:21.97

>>141
証拠出せよ
出せないなら自殺して詫びろ

**デフォルトの名無しさん** · 2025/09/28(日) 19:17:29.37

そもそも人間は左右対称だと閉区間と思い込むもんなの？
そこからおかしいんじゃないの？

**デフォルトの名無しさん** · 2025/09/28(日) 19:19:06.15

>>144
思い込まない
何の証拠もない中卒の妄想
ソースが無い

**デフォルトの名無しさん** · 2025/09/28(日) 19:21:01.28

話題になり得るのはAIエージェントが取り違えしてないかどうかチェックするためのテストコードをどうやってAIエージェントに漏れなく全ての箇所で書かせるかとかだろ
人間にとっての見やすさなんて無職の自白

**デフォルトの名無しさん** · 2025/09/28(日) 19:28:03.90

区間記号を全てgrepして該当箇所をファイルに書き出して書き込み禁止にし
その該当箇所全てでテストコードを書かことを義務付けてパスしないと認めない指示にするとかだな
記号なんて全くどうでも良い
テストするんだから

**デフォルトの名無しさん** · 2025/09/28(日) 19:29:08.83

区間記号の解釈とテストがどうなっているべきかも.mdに最初に書かせて
それを守ってない行動は全てリバート

**デフォルトの名無しさん** · 2025/09/28(日) 19:38:57.62

現在メジャーに使われているプログラミング言語で調査してみた
半開区間の指定が左右対称か左右非対称か？
【左右対称】C# Go Python Ruby Rust
【左右非対称】Swift

**デフォルトの名無しさん** · 2025/09/28(日) 20:05:41.70

>>139
> そもそもマシンコードに区間なんて存在しないんだから
> 内部的に２つの条件判断に置き換えるだけ

https://godbolt.org/z/q6T916rjW と https://godbolt.org/z/KvxEv7dsq じゃ結構違うと思うが何言ってる?

**デフォルトの名無しさん** · 2025/09/28(日) 20:16:56.42

>>150
だからアセンブラで書けよ無能
どんなマシンコードにコンパイルされるかすら知らねえ猿が吠えんな

**デフォルトの名無しさん** · 2025/09/28(日) 20:25:27.74

>>151
ちょっと何言いたいんだか分からんね。

**デフォルトの名無しさん** · 2025/09/28(日) 20:27:54.00

>>152
アセンブラ書けねえのか無知

**デフォルトの名無しさん** · 2025/09/28(日) 20:28:29.22

>>129
>現行の言語のデザインに何も疑問を持たないのはそれだけの人

>>129
違うデザインのものなんて無数にあるのに誰も支持しなかったことすら考えられないからお前は中卒無職ヒキコモリ脳障害なんだよ
自殺しとけ猿が

**デフォルトの名無しさん** · 2025/09/28(日) 20:29:19.56

>>152
分からんなら自殺しろ
アセンブラすら知らない猿が吠えんな
最終的にどんなマシンコードになるか知らないバカが妄想しても意味ねーから
消えろ
この世から

**デフォルトの名無しさん** · 2025/09/28(日) 20:33:56.40

> 最終的にどんなマシンコードになるか知らないバカが妄想しても意味ねーから

スマホで見て発狂してる可能性もあるかな?

**デフォルトの名無しさん** · 2025/09/28(日) 20:37:44.61

>>156
最適化レベルすら指定してない猿
無職か？

**デフォルトの名無しさん** · 2025/09/28(日) 20:48:48.21

> 最適化レベルすら指定してない猿

指定してる -Copt-level=2 が最適化指示とわからん人かな?

**デフォルトの名無しさん** · 2025/09/28(日) 20:59:03.90

AIって想像以上にアホだぞ

**デフォルトの名無しさん** · 2025/09/28(日) 21:12:11.28

>>124
Rubyは閉区間と半開区間の両方を提供したことと、閉区間に左右対称な..を採用したことでは
賢明だったが、半開区間に左右対称な...を採用したのは惜しい誤りだったな。..とも判別しづらいし。
..<か..~にすべきだった。

>>125
>>66にも書いたように、Swiftでは閉区間は...で左右対称、半開区間は..<で左右非対称だよ。
閉区間はPascalの..より.が1つ多い...だが、左右対称という点では共通する。

増分も指定できるように拡張することを見越すと、半開区間には..<より..~の方が適している。
開始値..増分..<終了値だと増分が負のとき変な感じがするが、開始値..増分..~終了値ならば
問題ないから。

もっともSwiftでは増分指定では記号を使わない。stride(from: 開始値, through: 終了値, by: 増分) の
ように省略不可の名前付き引数を書かせる。そして、名前付き引数だから順不同ということもなく、
この順でしか受け付けない。このようなガチガチの書式で固めたのもバグを防ぐための用心だろう。
Fortran, Juliaでは開始値:終了値:増分だがMATALAB, Octave, Scilabでは開始値:増分:終了値で
順序が異なるため、混同による書き間違えの恐れがあるから。

**デフォルトの名無しさん** · 2025/09/28(日) 21:13:50.83

>>131
>>116に挙げたJuliaの作者じゃないから、数学に合わせること自体に固執しているわけではない。
左右対称な..が閉区間を表すのが自然な感覚で、それに反するのはバグの元だからやめるべきだと
いうのが根源的な理由で、数学はそれに反していない例として挙げたに過ぎない。

人間は機械ではないから見た目に惑わされやすい。機械だけが相手なら半開区間をi!jで表せば
効率が最も良いし、多くの言語では破壊的変更も文法的に不要で好都合なはずだが、人間の
感覚では!は半開区間とは容易に結びつかない（:の変形と見なせば結びつかなくもないが）し、
|とも判別しづらいから不適当。

屁理屈を捏ねて自然な感覚に反することを強制するのは、ギークの村社会のキモい悪習としか
言いようがない。プログラム言語の記法の選定はUI設計の一種なのに、不自然で間違えやすい
記号を採用するのは工学的センスが絶望的にない。UIは美的にも心地良いことに越したことはなく、
その点でも見苦しい略語を多用するRustは落第だな。そもそも名前からして汚らしい。

>>144
基本ラテン文字の大文字全体を'A'..'Z'で表すのが素直な感覚（EBCDICのような化石はこの際
無視して良い）で、'Y'までしか含まないと言い張るのは無理がある。'A'..='Z'は冗長だし、
'A'..'['では何を意図しているかすぐには分からない人が多いだろう。

**デフォルトの名無しさん** · 2025/09/28(日) 21:25:20.44

Rustのイテレータがとてもわかりやすい
【C】i = 0 ; i < n; i++
【Rust】0..n
と
【C】i = 0 ; i <= n; i++
【Rust】0..=n
対応している

**デフォルトの名無しさん** · 2025/09/28(日) 21:32:15.76

>>158
書いてないぞ

**デフォルトの名無しさん** · 2025/09/28(日) 21:38:57.07

>>161
そんな感覚は無いのでお前の負け
ソース無し

**デフォルトの名無しさん** · 2025/09/28(日) 21:43:13.72

>>161
自然なのは左右対称とかどうでもいい猿の妄想じゃなくて
最も使われるものが最もシンプルに書けるという情報理論的効率性な？

**デフォルトの名無しさん** · 2025/09/28(日) 22:05:51.43

>>164
正直に白状しろ。心当たりが全くなくはないはずだ。

C++ STLの.begin()と.end()の組の.end()を書くときにも、もやもやする感覚が常に伴うな。
『リーダブルコード』に、

　プログラミングの命名規約では、包含／排他的範囲にbeginとendを使うことが多い。
　　でも、endは少しあいまいだ。例えば、「本の終盤（the end of the book）を読んでいる」の
　「end」は包含的だ。残念ながら英語には「ちょうど最後の値を超えたところ」を意味する簡潔な
　言葉がない。

と述べられている通り。簡潔な言葉がないなら作れば良かったと思う。例えば、endの次（next）だから
nendとか。無闇に造語すべきではないが、どうしても必要なら作れば良い。bitは成功例だろう。

とは言え、複数の本を本棚に並べ右端の横にブックエンドを置いたとき、.end()は本そのものではなく
ブックエンドだと考えれば、.end()はまあ納得できるから..ほど悪くはなく許容できる。

>>165
誤記予防という機能性を犠牲にしてたった1文字をケチる愚行。第一、閉区間より半開区間の方が頻繁に
使われるという主張も怪しい。作るプログラムによって異なるだろ。

**デフォルトの名無しさん** · 2025/09/28(日) 22:07:15.34

>>166
なんのソースもない中卒の妄想は意味ない
ソースを出せ
出せないなら自殺して詫びろ

**デフォルトの名無しさん** · 2025/09/28(日) 22:08:16.70

>>166
曖昧なことなど一つもない
定義を見れば良いだけ
定義以外の妄想してる時点で中卒無職だと確定する

**デフォルトの名無しさん** · 2025/09/28(日) 22:11:06.36

>>162
従来との対応関係のあることが最も重要なのでそれで正しい

**デフォルトの名無しさん** · 2025/09/28(日) 22:13:10.39

>>166
りーだぶるwwww
こーどwwwww

お前無職だろ？
そんな実績0の無能な猿が書いたゴミを流行りで買ってる時点で無職バレバレ

**デフォルトの名無しさん** · 2025/09/28(日) 22:15:00.74

>>167
低学歴ではないが、低学歴という煽りもここでは意味がないね。プログラム言語なんて小学生でも
分かる程度のものでしかないし、一般的感覚も自然言語と高校までの数学によって形成されるものだから。
そこから乖離した屁理屈をあれこれほざいても、ギークのキモい戯言でしかない。

**デフォルトの名無しさん** · 2025/09/28(日) 22:18:09.06

>>171
ソース出せない妄想と

**デフォルトの名無しさん** · 2025/09/28(日) 22:18:52.64

>>171
低学歴だから定義を無視して字面から妄想し
低学歴だからソースもないのに妄想を断定できてしまう

**デフォルトの名無しさん** · 2025/09/28(日) 22:23:17.24

>>162
>【C】i = 0 ; i <= n; i++
と
>【Rust】0..=n

は同じ動作になるとは限らないので何言いたいんだかわからん。

**デフォルトの名無しさん** · 2025/09/28(日) 22:26:42.41

いまこのスレで発狂してるやつ見てるとQiitaでアカウントBANされたコイツ思い出すんだよなあ。

https://web.archive.org/web/20221220153804/https://qiita.com/ashworth/items/a35270d88ac52116ef7d
> はい、私が勘違いしてました。

> 途中で、
>
> スクリーンショット 2022-12-19 184235.png
>
> みたいな突っ込みがあって、やっと問題文をちゃんと読み直して『あれ？』となったわけですが、
>
> 自分、基本的にTwitterでの間違いは死んでも認めない主義なので、そのまま押し切る事にしました。
>
> Twitterとかのネットは所詮遊び場なので「バトルしようぜ、Tweetバトル！俺が勝ったらテメェは俺以下だぁー！！」みたいなノリで強引に押し切ろうとしました。
>
> で、まぁ、惨敗したわけですけどねｗ

**デフォルトの名無しさん** · 2025/09/28(日) 22:27:15.68

以下の性質の良さの違いのため
プログラミングでは半開区間が多用されている

半開区間　(性質が良い)
・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になる

**デフォルトの名無しさん** · 2025/09/28(日) 22:27:24.30

>>173
カルト教団のむきになった反論そのものw　教祖様のお言葉がソースか?　

自然言語と高校までの数学表記が一般に広く受け入れられていること、それで根拠として十分。

**デフォルトの名無しさん** · 2025/09/28(日) 22:32:09.90

>>177

>>171
低学歴だから定義を無視して字面から妄想し
低学歴だからソースもないのに妄想を断定できてしまう

**デフォルトの名無しさん** · 2025/09/28(日) 22:38:40.96

区間指定の文法を持つ最近のメジャーなプログラミング言語では半開区間を簡単に表記できるようになっている
例えば
GoやPythonなどでは list[start:end]
C#やRustなどでは list[start..end]
いずれもendを含まない半開区間を意味している

**デフォルトの名無しさん** · 2025/09/28(日) 22:46:12.82

>>178
定義なんて所詮は教祖様がお作りになった教義に過ぎない。それを絶対視して変だと考えず、
変だと指摘する人にむきになって壊れたレコードのようにワンパターンな反応を繰り返す
カルト信者。

**デフォルトの名無しさん** · 2025/09/28(日) 22:47:22.28

>>180
定義はコンパイラの仕様
バカすぎる無職

**デフォルトの名無しさん** · 2025/09/28(日) 22:47:41.83

>>180
変なのはお前
だから無職なんだろ中卒

**デフォルトの名無しさん** · 2025/09/28(日) 22:49:02.93

>>176,179
これを入社試験の面接で説明できなきゃ不採用でいいわ
これ分からん奴はセンスが無さすぎる

**デフォルトの名無しさん** · 2025/09/28(日) 23:01:12.25

>>181
コンパイラは教祖様がお作りになった言語仕様に沿って作られたものだろ。

>>182
無限ループ、またの名を暴走と言うw

**デフォルトの名無しさん** · 2025/09/28(日) 23:01:37.54

>>184
これが無職

**デフォルトの名無しさん** · 2025/09/28(日) 23:25:09.36

>>183
初心者は仕方ないとしてもプログラミング歴のある人には必須な知識だと思う

**デフォルトの名無しさん** · 2025/09/28(日) 23:34:39.97

ここプログラム技術板で閉区間が自然だと主張して暴れてるやつはどこから来たお客さんなんだろう

**デフォルトの名無しさん** · 2025/09/28(日) 23:48:23.78

>>187
閉区間が自然だとは全く主張していないぞ。

・閉区間で書くのが便利な場合も半開区間で書くのが便利な場合もあるので、両方の書き方を
　提供するのが良い（勿論、前者の場合には閉区間が自然ということになるが）

・閉区間には左右対称、半開区間には左右非対称の記号を割り当てるのが自然で、バグを
　生みにくい

と主張しているだけ。

**デフォルトの名無しさん** · 2025/09/28(日) 23:54:41.82

現実のメジャーなプログラミング言語では>>179のように半開区間を簡潔に記述できることを重視している

**デフォルトの名無しさん** · 2025/09/29(月) 00:05:25.27

>>188
根拠0
証拠0
ソース0

バカすぎて論外

**デフォルトの名無しさん** · 2025/09/29(月) 00:05:49.17

>>188
こういうバカは無職なのが自然

**デフォルトの名無しさん** · 2025/09/29(月) 03:12:26.72

>>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言語は半開区間のみ

> 両方の書き方を提供するのが良い

半開区間のみを提供するのが良い
２つの書き方を提供するのはバグを生みやすい

あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名

**デフォルトの名無しさん** · 2025/09/29(月) 03:23:08.08

>>192
横からだけど
Goは言語機能が非常に弱くて
その半開区間の指定も部分フライス指定にしか使えない
イテレータとして機能しない
(switchやmatchなどの)パターンマッチングにも使えない

**デフォルトの名無しさん** · 2025/09/29(月) 07:48:42.16

>>192
＞あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名
　
TypeScriptコンパイラのことなら
　
Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#
　
という記事にまとめられているが
　
＞半開区間のみを提供するのが良い
＞２つの書き方を提供するのはバグを生みやすい
　
なんて理由は挙げられてないね。

**デフォルトの名無しさん** · 2025/09/29(月) 23:43:13.74

現実は>>179
理由は>>176
ということでいいのかな

**デフォルトの名無しさん** · 2025/09/30(火) 00:17:04.81

閉区間と半開区間のどちらが優れているということは誰も言ってないのに一人発狂してる人がいる感じ

**デフォルトの名無しさん** · 2025/09/30(火) 01:59:55.11

閉区間より半開区間が優れている
そのため半開区間を短い記述で指定できる文法を用意している言語が多い
短い記述の結果として半開区間が左右対称の記述になっているが誰も気にすることはない
半開区間の記述は左右非対称であるべきだとこだわっているキチガイは一人だけ

**デフォルトの名無しさん** · 2025/09/30(火) 02:52:38.16

無職の妄想に価値はない

**デフォルトの名無しさん** · 2025/09/30(火) 08:25:04.59

グレゴリオ暦のうるう年判定に延々とおかしなイチャモンつけてたashworthまんまだなｗ

**デフォルトの名無しさん** · 2025/09/30(火) 10:36:18.87

そもそも自転はずれるからな

**デフォルトの名無しさん** · 2025/09/30(火) 11:06:24.13

いまはこのルールでやりましょうというグレゴリオ暦を分かってないｗ

**デフォルトの名無しさん** · 2025/09/30(火) 12:34:48.41

グレゴリオ暦のうるう年の判定ルール
・西暦年が4で割り切れる年はうるう年となる
・ただし、西暦年が100で割り切れる年はうるう年としない
・さらに、西暦年が400で割り切れる年は例外的にうるう年とする

**デフォルトの名無しさん** · 2025/09/30(火) 12:39:42.96

低学歴がなぜ低学歴なのかよくわかる

**デフォルトの名無しさん** · 2025/09/30(火) 12:40:27.16

>>201
バカすぎてルールを理解できないことを正当化するためにルールがおかしいと吠えたまま死ぬ
これが低学歴の人生

**デフォルトの名無しさん** · 2025/09/30(火) 12:40:59.11

そういうゴミクズを雇ったら終わりなので学歴システムがある
人間判定試験
猿を雇わないようにするための仕組み

**デフォルトの名無しさん** · 2025/09/30(火) 23:54:22.10

>>188
閉区間ではなく半開区間をサポートするプログラミング言語が多い理由を考えてみよう
それらの言語は半開区間に左右非対称の記号ではなく簡潔な記号を割り当てている理由を考えてみよう

**デフォルトの名無しさん** · 2025/10/01(水) 00:59:06.36

算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は

**デフォルトの名無しさん** · 2025/10/01(水) 01:38:56.41

> そもそも自転はずれるからな

地球の自転周期が変わったとして影響があるのは1日の長さなんだがｗ

**デフォルトの名無しさん** · 2025/10/01(水) 02:15:45.08

>>207
多用する半開区間に短い記号を充てるのが正解だと思う
しかしPythonやGoの start:end はあまりにも短すぎて用いる場所によっては文法的に曖昧になる可能性があるためなのか
現状はスライスのインデックス部分 a[start:end] でしか用いることができない
例えばmatch文のcaseでは指定できないため case x if start <= x < end と書く必要がある
イテレータとしても指定できないため for i in range(start, end) と書く必要がある
これら全て同じ記法で書けると好ましい

**デフォルトの名無しさん** · 2025/10/01(水) 21:52:18.72

Rustは同じ扱い
buf[100..200]
for i in 100..200 { … }
match x {
100..200 => …,
…
}

**デフォルトの名無しさん** · 2025/10/01(水) 23:34:49.32

>>206
>それらの言語は半開区間に左右非対称の記号ではなく簡潔な記号を割り当てている理由を考えてみよう

教祖様がお作りになった教義だから。教祖様の好みが強く反映されているとしか言いようがない。

>閉区間ではなく半開区間をサポートするプログラミング言語が多い

事実ではなかろう。

・閉区間しかない
　Ada, bash, Delphi, Elixir, F#, Fortran, Groovy, Haskell, Julia, MATLAB, OCaml, Octave, Pascal, Perl, PowerShell, R, S, Scilab, Wolfram
　（Wolfram以外は左右対称記号を使用、Wolframはほぼ左右対称の;;を使用）

・半開区間しかない
　C#, D, Go, Python
　（すべてが左右対称記号を使用）

・両方ある
　Kotlin, Nim, Raku, Ruby, Rust, Swift, Zig
　（これらのうち、
　　　閉区間に左右対称記号を使用：Kotlin, Nim, Raku, Ruby, Swift, Zig
　　　半開区間に左右対称記号を使用：Ruby, Rust, Zig）

※抜けている言語や記憶違いなどがあるかも知れないので、見つけたら指摘してもらいたい

以上を一覧すれば、半開区間しかない言語は少ないし、閉区間に左右対称記号を使う言語は多いし、
半開区間に左右対称記号を使う言語は少ない。要するに、一般的感覚に敢えて背く仕様の言語は
少ないことが看取される。

**デフォルトの名無しさん** · 2025/10/01(水) 23:35:20.38

>>207
圧縮ファイルを直読みできる超人さんですか?w

短さを馬鹿の一つ覚えみたいに持ち出しているが、間違えにくさを犠牲にしてまで達成すべきものではない。
人間は機械ではないのでうっかり間違えやすい記号を宛てないのが賢明で、たった1文字をケチるのは愚行。

正確に言えば機械も生の状態では間違えるから、エラー訂正符号を付加して無謬に見せかけているだけなので、
人間にも機械にも最短ではなくそれぞれの間違え方を防ぐような追加の情報も必要だという訓戒に纏められるな。
そこを疎かにするのは欠陥設計。

**デフォルトの名無しさん** · 2025/10/01(水) 23:36:14.72

>>211

算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は

**デフォルトの名無しさん** · 2025/10/01(水) 23:37:07.68

>>212
え？圧縮ファイル？
何言ってんのこの中卒無職脳障害
そんなの関係ねえよ猿が

情報理論的な効率性の話しかしてないのに中卒だからわかんねえのか自殺しとけ猿が

**デフォルトの名無しさん** · 2025/10/01(水) 23:38:06.41

>>212
お前が低学歴で人間じゃないだけ
お前は無職で人間の世界から排除されてるから人間の世界に口出しする権利ないよ
参加お断り

**デフォルトの名無しさん** · 2025/10/01(水) 23:51:28.21

>>214
馬鹿には皮肉の解説が必要だったか。情報理論的な効率性を徹底的に追求したのが圧縮ファイルだろ。
それは人間には勿論読めないが、もう少し緩く追求した半開区間に..を使う表記も人間にはやっぱり
間違いやすい。お前がそんなことはないと言い張るなら、さぞかし凄い超人なんだろうねーという皮肉。

たった1文字追加するだけで効率性と間違えにくさのバランスが取れた表記になるのに、ムキになって
否定するのは愚か。

**デフォルトの名無しさん** · 2025/10/01(水) 23:56:05.16

>>216
圧縮ファイルなんて使ってない
人間の世界では最短符号を使って人間は読んでる
無職はそれが読めないから誰も雇わない

**デフォルトの名無しさん** · 2025/10/01(水) 23:56:30.77

>>216
お前が間違えてもどうでもいい
だってお前は人間じゃないし人間の社会に参加出来ないから

**デフォルトの名無しさん** · 2025/10/01(水) 23:57:04.34

>>216
人間は間違えない
猿は間違える
だから猿を雇わない
よってお前は無職
猿だからな

**デフォルトの名無しさん** · 2025/10/02(木) 00:00:52.83

>>216
C#の半開区間指定start..end読みやすくて良いと思うよ
閉区間だと間違える人はいない

**デフォルトの名無しさん** · 2025/10/02(木) 00:02:09.92

人間は間違えない
猿は間違える
だから猿を雇わなきゃいいだけ

**デフォルトの名無しさん** · 2025/10/02(木) 00:02:41.34

猿に合わせて人間のルールを変えるわけねえだろ
猿を排除するのが最善

**デフォルトの名無しさん** · 2025/10/02(木) 00:44:06.46

>>211
それら閉区間しかないプログラミング言語は現代のメジャーな言語ではないな
センスが悪いとメジャーな言語になれないことがわかった

**デフォルトの名無しさん** · 2025/10/02(木) 01:12:51.54

>>202
『あなたは本当に「プログラミングができない、向いてない」のか？〜うるう年判定プログラムで考える〜』
https://qiita.com/kjm_nuco/items/fd16c2af6b089c4849cd

という記事のコメ欄でashworthが他のコメントに絡んでたけど(垢BAN済み)、記事のコード見ると

> year = int(input())
> if year % 400 == 0: # 400の倍数なら「うるう年です。」
> print("うるう年です。")
> elif year % 100 == 0: # 100の倍数なら「うるう年ではありません。」
> print("うるう年ではありません。")
> elif year % 4 == 0: # 4の倍数なら「うるう年です。」
> print("うるう年です。")
> else: # どれにも当てはまらなければ、「うるう年ではありません。」
> print("うるう年ではありません。")

400は100の倍数、100は4の倍数を利用したグレゴリオ暦の説明の逆順で判定するけったいなコード書いてんなあナンダコレ?
まあ記事はNucoなんでセンスなくて当たり前なんだけど、ashworthがこれに絡んでなかった辺りやっぱセンスないわなｗ

**デフォルトの名無しさん** · 2025/10/02(木) 01:14:57.85

まともな言語がいずれも半開区間をサポートしているのは偶然ではなくて、
配列やリストやベクタあるいは文字列などの連続領域の一部分いわゆるスライスを言語で扱おうとすると、
その区間を指定する必要がでてくる。

まともな汎用言語ならそのスライスと区間指定をサポートするのは必然で、
しかも閉区間は扱いにくいことが判明しているわけだから、
結果的に半開区間をサポートしているか否かでまともな言語か否かが判明することになっている。

**デフォルトの名無しさん** · 2025/10/02(木) 04:38:08.95

>>224のコードってそんなに変かな？　自分もこんな感じに書くと思うが。

**デフォルトの名無しさん** · 2025/10/02(木) 05:00:19.18

>>226
動くコードは無数に考えられる。
しかし保守性を考慮すると、
元の文章に対応したコードのみが正解。
元の文章と逆順に書いた場合、
何か理由が添えてない限り失格でクビだろうね。

**デフォルトの名無しさん** · 2025/10/02(木) 07:15:16.83

ソース読めよ

Check out this DeepWiki page https://deepwiki.com/search/calendarisleap_6015837d-0d22-4326-870d-fd0623c9acd7

**デフォルトの名無しさん** · 2025/10/02(木) 07:34:34.02

なるほど、if文のネストみたいな感じで書くのだとしたらそれはかえって分かりにくいのではと思ったけど、and or で1行で書いちゃうならスッキリしているね。

**デフォルトの名無しさん** · 2025/10/02(木) 08:18:23.33

if文使った時点で不採用
print文使った時点で不採用

正解は
・数式・比較演算子と論理演算子で書く
・デバッガで各論理式の評価を確認してprint文を使わない

**デフォルトの名無しさん** · 2025/10/02(木) 08:19:21.13

deepwikiでソースコードに聞け
低スキルの「エンジニア」同士で低スキルを伝播しても害しかない

**デフォルトの名無しさん** · 2025/10/02(木) 08:24:53.30

print関数はさすがに説明の便宜のためでしょ。

**デフォルトの名無しさん** · 2025/10/02(木) 08:26:48.25

知りたいgithubのアドレスを取得
https://github.com/python/cpython

アドレスのgithubをdeepwikiに置換
https://deepwiki.com/python/cpython

最下部のフォームに質問すればソースコードをソースにして回答する

**デフォルトの名無しさん** · 2025/10/02(木) 08:29:36.47

で
このdeepwikiもMCPでアクセスできるので
AIエージェントがコーディングのお作法を実装前にDeepWiki MCPで確認してソースコードをソースにして手順を確立してメモしてからそれを見ながら実装を開始するように出来る

低スキルエンジニア同士の会話など害しかない

**デフォルトの名無しさん** · 2025/10/02(木) 08:45:54.05

速さ優先ならこれとはまた異なってくるのだろう
return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)

**デフォルトの名無しさん** · 2025/10/02(木) 13:03:09.54

return False

**デフォルトの名無しさん** · 2025/10/02(木) 13:37:06.50

> それ、問題文の条件のまま書いちゃダメなんですよね。
> 「ただし」がある場合は前出の条件を否定してくるので、条件の順番通りに書くと破綻します。
> だから、「ただし」がある場合は条件を逆に記述していくのが鉄則です。
　
ashworthさん、何言ってんの?

**デフォルトの名無しさん** · 2025/10/02(木) 23:03:29.56

>>219
これまでの書き込みからお前はRust信者と推測されるが、「言語仕様で明確に定義されているのに数学につられて
間違えるのは低学歴・無職・猿」という煽り文句がブーメランになることに気づいていないのか?

C, C++ではif (a = b)という書き方が許されているが、数学では=が比較にも使われるため、比較するつもりで
if (a = b)とうっかり書き間違え、読み返しても間違いを見落とす恐れがあるので、C#やRustではこういう書き方を
できなくした。お前の煽り文句に従えば、代入は=、比較は==と言語仕様で明確に区別して定義されているのに
数学につられて間違えるのは低学歴・無職・猿で、C#やRustは低学歴・無職・猿向けの言語ってことになるねw

仮にお前がRustでなく他の言語の信者だとしても、似たようなブーメランを見つけることができるだろう。

Rustは他にも変数宣言でmutをいちいち書かせるなど過保護な安全性が設計思想にあるのに、半開区間..では
危うさを放置するのはチグハグだな。

あと、ここはプログラマー板じゃなくてプログラム板だから、別に職業プログラマ向けというわけではなく、
プログラムに関する見識は職を得ることに結びつかない。職業プログラマなんてIT土方とも揶揄されて
威張れるもんじゃないし、まして特定の言語と一蓮托生で必死になってるようではなー。お前の煽り文句は
明後日の方を向いているw

**デフォルトの名無しさん** · 2025/10/02(木) 23:03:54.24

>>223
ユーザーは区間の記法だけによってどの言語を使うか選んでいるわけではないから、一概には言えない。
Pythonはずぼらだからはびこってしまった。あんな害蛇はさっさと駆除すべきだな。その点、Rustは
繁文縟礼の塊なのであまり普及せず実害は少ない。

C#はユーザーを十分獲得した後の2019年に半開区間..を初めて導入した。.NET兄弟のF#とPowerShellが
..を閉区間に既に割り当てていたのに、そして開発責任者はPascalと縁が深いのに、何であんな変な記法を
許してしまったの解せない。

**デフォルトの名無しさん** · 2025/10/02(木) 23:12:57.09

>>238
いやRustなんか興味ないし知らん
どうでもいい
脳障害は日本語すら読めないだけ
人間は間違えないので猿を雇わなければ良いだけ
猿のために人間のルールを変えるわけない

**デフォルトの名無しさん** · 2025/10/03(金) 00:09:20.16

半開区間に左右非対称を採用してる言語はSwiftだけじゃね？

半開区間の記法
【start:end】 Go Python
【start..end】C# Rust Zig
【start...end】Ruby
【start..<end】Swift

この現状で左右対称を採用している言語はダメだと叩いている人は偏った異端者かと

**デフォルトの名無しさん** · 2025/10/03(金) 01:07:33.20

1991 Python
1995 Ruby
2000 C#
2009 Go
2010 Rust
2014 Swift
2015 Zig

後発の方が先達の反省が活かされた洗練された記法を採用してる可能性は普通に考えられるかな

**デフォルトの名無しさん** · 2025/10/03(金) 01:23:00.07

C#が半開区間start..endを導入したのは2019年リリースのC# version 8.0

**デフォルトの名無しさん** · 2025/10/03(金) 08:33:47.40

『Cなら知ってるんですけど、C++ってできますか？』
　
Cた間違い

**デフォルトの名無しさん** · 2025/10/03(金) 08:35:11.18

CやC++初心者は間違い探し的に読むと良い記事。

**デフォルトの名無しさん** · 2025/10/03(金) 10:41:32.04

>>244
モダンC++と言いつつ大昔の古臭いC++11で草
さらにC++11と言いつつ中核のスマートポインタを割愛で草

**デフォルトの名無しさん** · 2025/10/03(金) 11:02:03.70

長文おぢウザい

**デフォルトの名無しさん** · 2025/10/03(金) 23:27:23.05

>>241
>>211に挙げた「両方ある」の7言語のうち「半開区間に左右対称記号を使用」の3言語を除いた4言語、
つまりKotlin, Nim, Raku, Swiftが半開区間に左右非対称の記号を使用している（Kotlin, Nim, Swiftは
..<で、Rakuは...^）。Rakuには左半開区間^...と開区間^...^もあり、4種類すべての区間を書ける。
これらに含まれる...は…と1文字で書いても良い。

Rubyは閉区間..より半開区間...の方が長いから、>>165がやたらこだわっている情報理論的効率性とやらには
反しているな。

**デフォルトの名無しさん** · 2025/10/03(金) 23:28:02.03

>>238
> 変数宣言でmutをいちいち書かせるなど

これはプログラマーに
mutable宣言を意味するmutなどを書かせるべきか
immutable宣言を意味するconstなどを書かせるべきか
どちらをデフォルトにすべきかという問題だね

これはimmutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
immutableをデフォルトとして必要不可欠な変数のみmutable宣言させるのが正しいと思われる
プログラマーの手間もその方が少ない

**デフォルトの名無しさん** · 2025/10/04(土) 14:05:10.36

Qiita Conference 2025 Autumn というので
https://qiita.com/official-campaigns/conference/2025-autumn

> 今のコンピュータはAIにもWebにも向いていないので作り直そう
> 2018年にAttentionが発表され、2022年末にLLMが登場して以降、GPUを用いた生成AIがあらゆるコンピューティングの活用を塗り替えていますが、実はGPUが生成AIに向いていないことをご存知でしょうか？
> 他にも、現代コンピュータアーキテクチャ自体が約70年前に構想されて以来、スループット／レイテンシ／電力消費に根本的な課題を抱えたままで、WebやIoTなどの大量ユーザー利用／データ利用と言った現代に求められる様々は「エンジニアが無理やり何とかしている」と言う実態があります。
> こうした課題を生み出す裏側を解説した後、性能と省電力を圧倒的に引き上げるための考え方／イノベーションを共有し、実際の解決実装例をご紹介します。

コイツに講演させちゃうんだなあ。ゲスト講演ということだけどどうやって人選してるのだろう?

**デフォルトの名無しさん** · 2025/10/04(土) 19:45:26.17

>>250
課題を生み出すwwww
省電力を引き上げるwwwww

これだけで価値がないとわかる

**デフォルトの名無しさん** · 2025/10/04(土) 21:38:51.49

>>250
山崎かなと思ったら福岡Elixirって書いてあったから同族か

**デフォルトの名無しさん** · 2025/10/04(土) 23:29:54.72

>immutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
マイナーな言語しかなくね？
「そういう言語がある」だけで、多くの人にとってはそれが便利だと思われてないと思うぞ

**デフォルトの名無しさん** · 2025/10/04(土) 23:33:11.13

Elixirの軽量スレッドで並列処理が効率化できてスパコン的用途にも使えると思ってる人たちだからなあ、つける薬がない。

**デフォルトの名無しさん** · 2025/10/04(土) 23:59:14.21

>>253
immutableだけだと不便で制限が生じる
その一方でプログラムはなるべくimmutableを中心にしてmutableは補助的に使うと良いコードになる

**デフォルトの名無しさん** · 2025/10/05(日) 23:10:55.15

Elixirでフィボナッチ数列をいろいろ書いてみた Part. 5
https://qiita.com/zacky1972/items/1d2dd390454e80f39d3f
> Fibonacci with Matrix は素晴らしく速いですね！

Elixirで順に指定個数の素数を列挙する関数をEnum, Stream, Flowで作ってみた
https://qiita.com/zacky1972/items/2cdc68f56c2b42b803e1
> 1000,10000個の時にはFlowが最速でした．

1000番目のフィボナッチ数計算すんのに 1.33m秒とか、ベンチマーク結果なんでか編集で消えてるんだけど

> prime_flow 11.84 84.48 ms ±1.22% 84.27 ms 89.85 ms

20000未満の素数算出すんのに 84m秒って遅すぎね?

福岡Elixirってこんな記事ばっかりだな。んで、身内でいいね付けあってる。

**デフォルトの名無しさん** · 2025/10/05(日) 23:41:25.21

スキルがあるのに福岡なんかにある仕事の給料で耐えられるわけない

**デフォルトの名無しさん** · 2025/10/06(月) 00:44:13.25

>>256
> 20000未満の素数算出すんのに 84m秒って遅すぎね?

ベンチマーク出すのに84m秒って速すぎね?
84m秒のベンチマークを100回やるのがいいのか8.4秒のベンチマークを1回やるのがいいのかで遅いほうがいいと思うんだが

**デフォルトの名無しさん** · 2025/10/06(月) 01:20:13.00

フィボナッチ数は行列累乗を理解してないから乗数の数だけ掛け算やってるし、素数の方は「エラトステネスのふるいを純朴に利用して」と書いてる割に剰余計算で余りがでたものを倍数としてフィルタする処理になってて全然エラトステネスのふるいじゃないなあ、ダメだこりゃ。

どちらの記事もアルゴリズムへの理解がなくて効率悪いことやってるんだが、こういう記事平気で公開してる人が

地球温暖化とコンピュータのエネルギー消費の問題にElixirで立ち向かう〜「コンピュータと地球温暖化は 決して無縁ではない」(2022年版)
https://qiita.com/zacky1972/items/a67459bf36f7b369b946

なんて記事書いてて頭が痛い。
これで大学の先生ってなあ、冗談なら良いのに。

**デフォルトの名無しさん** · 2025/10/06(月) 01:25:15.29

>>258
84m秒は100回実行した中央値らしいしそこは問題ないと思う。

> ##### With input 10000 #####
> Name ips average deviation median 99th %
> prime_flow 11.84 84.48 ms ±1.22% 84.27 ms 89.85 ms
> prime_stream 1.14 874.15 ms ±21.02% 787.90 ms 1243.42 ms
> prime_enum 0.81 1233.13 ms ±0.51% 1235.09 ms 1241.00 ms

**デフォルトの名無しさん** · 2025/10/06(月) 06:36:07.31

>>259
エラトステネスのふるいは、
作業メモリをその数だけ必要とすることと引き換えに、
足し算だけで素数を求めることができるアルゴリズムだから、
遅い剰余算を用いた時点で失格となりますね。
エラトステネスのふるいの場合をベンチマークとして比較しているわけでもないようてすね。

**デフォルトの名無しさん** · 2025/10/06(月) 08:49:11.07

この先生はElixirみたいなニッチな言語研究するより先にアルゴリズムの勉強したほうが良いと思う。
現状では学部の学生並みの知識もある気がしない。

**デフォルトの名無しさん** · 2025/10/09(木) 14:36:21.61

『【C言語】char型の落とし穴~オーバーフロー~』
　
charの変数の値はintに昇格されてから加算されるのでこの場合オーバーフローしないし、intからcharに型変換する際にビットが捨てられるのもオーバーフローじゃないけど、この記事は何をオーバーフローと呼んでいるのか?

**デフォルトの名無しさん** · 2025/10/09(木) 15:40:17.99

Cしか使えない特殊な環境ならともかく
勝手に異なる型へ自動変換されて困ったことになる弱い型付け言語のCを使ってる情弱の知識はそんなもんだ

**デフォルトの名無しさん** · 2025/10/10(金) 00:22:23.86

https://qiita.com/GonT38847064/items/0770153fd0fb05abaa8a#comment-b7ef583e34653899a04a
> ご指摘ありがとうございます。数値を修正しました...

コンパイルエラーが出るよう修正するとかｗ
https://gcc.godbolt.org/z/565sb5PEh

**デフォルトの名無しさん** · 2025/10/10(金) 01:56:58.97

今となっては未定義動作だらけの欠陥言語Cにこだわる人はほぼ異常者だな
残りは特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ

**デフォルトの名無しさん** · 2025/10/10(金) 08:25:59.69

組み込みの世界知らない人かな

**デフォルトの名無しさん** · 2025/10/10(金) 09:05:26.07

C以外は特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人って事?

**デフォルトの名無しさん** · 2025/10/10(金) 09:11:11.73

>>267
それはコレやね

>>特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ

**デフォルトの名無しさん** · 2025/10/10(金) 09:17:04.99

>>268
C以外に未定義動作だらけなクソ言語あるの？

**デフォルトの名無しさん** · 2025/10/10(金) 09:30:05.88

> C以外に未定義動作だらけなクソ言語あるの？
　
C++も聞いたことない人かあ

**デフォルトの名無しさん** · 2025/10/10(金) 10:03:41.96

C/C++は同罪だね
C++が失敗した理由はいくつも挙げられてきたけど
拡張方法の失敗に加えてCの未定義動作を埋めきれなかったことが響いてる

**デフォルトの名無しさん** · 2025/10/10(金) 10:10:16.74

Javaでもメソッド無いの初期化されていない変数とかで失敗するけど
未定義動作になるのを言語のせいとか言ってるけど自分が必用な値が自動でセットされるわけじゃないのだからそういう奴ってバグを作り出す

**デフォルトの名無しさん** · 2025/10/10(金) 10:23:29.55

>>273
Javaでは未定義動作にならないため問題は起きません
ローカル変数は初期化しないとエラー
インスタンス変数はデフォルト値で自動的に初期化されます
デフォルト値は各型により0やfalseやnullなど定まっています
Cの実行するたびに値が変わる問題はJavaでは起きません

**デフォルトの名無しさん** · 2025/10/10(金) 12:28:43.96

最適化のなしかありかで挙動の変わる言語があるらしいけどそういうのは最悪。
　
fn main() {
　　let mut sum: i8 = 0;
　　let mut num: i8;
　
　　num = 100;
　　sum += num;
　
　　num = -10;
　　sum += num;
　
　　num = 120;
　　sum += num;
　
　　println!("3つの数の合計は{}です。", sum);
}

**デフォルトの名無しさん** · 2025/10/10(金) 12:45:31.67

その辺見越して大きい値扱える変数使って明示的にうまいことやるからどうでもいいんだよなあ

**デフォルトの名無しさん** · 2025/10/10(金) 12:56:29.02

>>275
debug modeとrelease modeの違い
標準状態ではdebug modeで動作
実行時コストをかけて様々な検出をしてくれる
release modeでは明示的な実行時コスト指定ex. checked_add()などがある時のみ

**デフォルトの名無しさん** · 2025/10/10(金) 17:34:11.75

x86やARMでオーバーフローチェックのコストなんて大したものではないので、最適化有効の場合でもオーバーフローチェックは行うのがフェイルセーフ的に正しいな。
オーバーフローチェックのコストが問題になるレアケースでは記述を変える対応が良い。
そういう判断できなかった辺りが残念言語なんだよなあ。

**デフォルトの名無しさん** · 2025/10/10(金) 19:59:29.06

>>278
オーバーフローチェックのコストはとんでもなく高いんだよ。
演算命令1つ行なう毎に、そこで立った条件フラグによる条件分岐を毎回行なう必要がある。
これはコンパイラが行なうコードの並べ替えやループの展開やベクトル化などを全て阻止してしまう。
劇的に遅くなることが判っているよ。

さらにアセンブリ言語を書いたりコンパイル結果を見たりしたことがあれば理解しやすいけど、
条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。
そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。
常にオーバーフローフラグを必要とするならそれもできなくなってしまう。
条件フラグをレジスタやメモリに一時退避させるコストもかかってくるんだよ。

**デフォルトの名無しさん** · 2025/10/10(金) 21:05:08.50

いまどきのプロセッサは分岐予測も優秀だし分岐しない条件分岐命令は大してペナルティならねぇよアホか。

**デフォルトの名無しさん** · 2025/10/10(金) 21:12:19.16

＞条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。
＞そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。
　
知らないこと想像で書いてて大変宜しいｗ

**デフォルトの名無しさん** · 2025/10/10(金) 21:29:12.39

>>280
理解できていないようだけど、
演算命令の順序が固定かつシリアル化されてしまうことが大きいんだよ。
命令順序の入れ替えは最適化の基幹であるとともに、並列展開もできなくなってしまう。
さらに条件フラグの保存コスト問題も生じてしまう。

**デフォルトの名無しさん** · 2025/10/10(金) 21:32:04.92

>>281
x86など使ったことある人には常識だけど、
条件フラグの更新を伴う加算と伴わない加算としてADD命令とLEA命令の使い分けをコンパイラも多用しているよ。
それ以前の演算で反映された条件フラグを変化させないまま、
LEA命令によって加算や一部の乗算及びその組み合わせ演算をできる利点があるためだよ。

**デフォルトの名無しさん** · 2025/10/10(金) 23:12:50.77

実例挙げられない辺りが限界なんだろうなあｗ

**デフォルトの名無しさん** · 2025/10/10(金) 23:19:18.23

>>284
実例を既に>>283で挙げたよ。
もしかしてアセンブラ使ったことすらなくて理解すらできなかった？

**デフォルトの名無しさん** · 2025/10/10(金) 23:42:12.34

どのコンパイラがどういうコード吐いてるかも示せないで実例とか言ってるのはたまげたなｗ

**デフォルトの名無しさん** · 2025/10/11(土) 00:12:43.19

ADDではなくLEAでフラグ変化させずに加算演算するのは手動でもコンパイラでも基本
この常識を理解できない低レベルな人はコード書いたりコンパイラ生成コードを見たことすらない人

**デフォルトの名無しさん** · 2025/10/11(土) 10:05:05.53

コンパイラが出力した「条件フラグを変更せず保持したまま演算を行なう」コードの実例から逃げてるとこ見ると「LEAで加算ができる」が知識の限界の人かな

**デフォルトの名無しさん** · 2025/10/11(土) 10:12:37.71

> コンパイラ生成コードを見たことすらない人
　
このスレでCompiler Explorerのアドレス貼ってる人は珍しくないので（>>150とか）同様にして見せてやれば良い。

**デフォルトの名無しさん** · 2025/10/12(日) 03:13:55.78

Rust信者ってこんなもんだなあとういうのはまあ納得

**デフォルトの名無しさん** · 2025/10/12(日) 03:35:45.68

Rust？
関係ないだろ

**デフォルトの名無しさん** · 2025/10/12(日) 05:25:08.36

マシン語にするプログラミング言語は最適化によって意図と違うコードになることがあるという話をしたいんだろ。

**デフォルトの名無しさん** · 2025/10/12(日) 12:59:12.78

> Rust？
> 関係ないだろ

>>275からの話の流れが理解できない人かな

**デフォルトの名無しさん** · 2025/10/12(日) 19:07:27.09

>>275
このRustプログラムが最適化あり（リリースビルド）／最適化なし（デバッグビルド）で挙動が変わる理由は、i8型の符号付き整数オーバーフローの扱い方が状況によって異なるためです

最適化なし（デバッグビルド）
sum += numで加算の結果がi8の範囲（-128～127）を超えてしまうと、panicになるため意図した出力が得られず、エラーが発生します

最適化あり（リリースビルド）
オーバーフローのチェックが省略されて二の補数によるラップアラウンド（桁あふれの結果として範囲内に収める計算）が行われます

**デフォルトの名無しさん** · 2025/10/12(日) 19:15:49.53

リリースビルド（最適化あり）でもオーバーフローを検出し、デバッグビルド（最適化なし）と同じ挙動にする方法があります

Cargo.tomlに以下を追記します：
[profile.release]
overflow-checks = true

リリースビルドでも整数オーバーフローが発生するとpanic（異常終了）になります

**デフォルトの名無しさん** · 2025/10/12(日) 20:41:41.77

デフォで安全側に倒してない時点で残念言語だな

**デフォルトの名無しさん** · 2025/10/12(日) 21:03:27.80

オーバーフローでプログラムを中断したいのか
オーバーフローをエラーとして返したいのか
オーバーフローを値として受けて活用したいのか
オーバーフローは影響しない処理なのか
一般的に様々な状況が考えられる
これは安全性の問題とは関係がない

**デフォルトの名無しさん** · 2025/10/12(日) 21:59:02.37

> オーバーフローでプログラムを中断したいのか
> オーバーフローをエラーとして返したいのか
> オーバーフローを値として受けて活用したいのか
> オーバーフローは影響しない処理なのか
> 一般的に様々な状況が考えられる
　
話についてこれない人かな

**デフォルトの名無しさん** · 2025/10/12(日) 22:06:32.37

>>298
オーバーフローをどう処理したいかはプログラミングの内容に依って変わる
これは安全性の問題ではない

**デフォルトの名無しさん** · 2025/10/12(日) 22:47:47.29

オーバーフローを無視して処理を続けていいわけはないので安全性の話なんだよなあ
何言ってんのこの人ｗ

**デフォルトの名無しさん** · 2025/10/12(日) 22:55:53.45

オーバーフローは無視できる処理もあるし、オーバーフローが起きない場合もあるわけだから、そこはケースバイケースやろ。
状況次第としか。

**デフォルトの名無しさん** · 2025/10/12(日) 23:07:39.13

生成コードで考えると
オーバーフローフラグが立つ演算命令1つ毎に直後にオーバーフローの有無で判断する分岐命令を必ず入れることになるがそれは効率が悪すぎる
しかも命令順序の固定化と直列化を招いてしまう
現在のCPUは命令順序の入れ替えと並列化で最適化をするからそれができないと劇的に遅くなる
不要なオーバーフローチェックは可能な限り避けるべき

**デフォルトの名無しさん** · 2025/10/13(月) 02:39:47.42

>>290
オーバーフローのチェックのコストの重さ問題は特定の言語に関係なく全ての言語で生じる話だよ
そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ
そして必要に応じてオーバーフローのチェックをする関数を呼び出すなどして対応するよ

**デフォルトの名無しさん** · 2025/10/13(月) 02:43:31.43

最適化のなしかありかで挙動の変わると言ったのが間違い
最適化でなくオーバーフローチェックのなしかありかで挙動の変わる
デフォで安全側に倒してないと言ったのも間違いでデフォでデバッグビルドを作って安全側に倒してオーバーフローチェックがある
劇的に遅くなるからリリースビルドのデフォでオーバーフローチェックがないのは妥当

**デフォルトの名無しさん** · 2025/10/13(月) 09:36:39.69

配列アクセスで範囲チェックしてくれる言語についてオーバーフローチェックは「効率ｶﾞｰ」と発狂してるのｵﾓﾛｲｗ
お前らRustも実行効率もなんも分かってないなｗ

**デフォルトの名無しさん** · 2025/10/13(月) 16:43:07.06

配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項
コンパイラが範囲内であると判断できれば最適化で安全にチェックをなくすことが可能
さらにRustなどではシーケンシャルアクセスの場合にインデックスアクセスが使われないため安全性と実行効率を両立させている

**デフォルトの名無しさん** · 2025/10/13(月) 22:59:28.18

> 配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項

オーバーフローチェックをやんなくて良い理由なんてないし。

> コンパイラが範囲内であると判断できれば最適化で安全にチェックをなくすことが可能

それはオーバーフローチェックも同様。>>275のコードなんてコンパイル時にオーバーフローするか判定できるわけだし。

**デフォルトの名無しさん** · 2025/10/13(月) 23:06:55.10

＞配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項
　
プログラムが完璧に作られてれば範囲チェックなんて要らんぞ？何言ってんの？？

**デフォルトの名無しさん** · 2025/10/13(月) 23:21:03.25

>>308
本気で言ってるのかね？
範囲外アクセスでどれだけ多くのセキュリティホールを招いてきているか

**デフォルトの名無しさん** · 2025/10/13(月) 23:38:05.02

配列などのメモリ範囲外アクセスチェックは必ずしなければならない。
その上でコンパイラが範囲内だと保証できれば最適化により範囲内チェックを省略する。
ミスを起こし得る人間がそれを判断してはいけない。

**デフォルトの名無しさん** · 2025/10/14(火) 00:00:34.05

Cで配列などのメモリ範囲外アクセスチェックは必ずするかと言ったらしないよね？
「必ず」というのはそれを必ずするライブラリを使うということで
フリーの配列ライブラリなんてないよね？
配列ライブラリを使うならRustでいいと

**デフォルトの名無しさん** · 2025/10/14(火) 00:04:17.51

>>311
そのためにC/C++は大量のセキュリティホールを生み出してきた
そんなことは許されない時代になった
C/C++はそれ以外にも多くの未定義動作など問題が多すぎるため使うべきではない

**デフォルトの名無しさん** · 2025/10/14(火) 00:14:41.04

「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

米国ホワイトハウスが開発者に対しC++やC言語からRustやJavaなどのメモリ安全性に優れたプログラミング言語への移行を勧める
https://gigazine.net/news/20240229-whitehouse-urges-use-rust-java/

**デフォルトの名無しさん** · 2025/10/14(火) 00:14:44.98

配列アクセスでの範囲チェックは絶対必要だけどオーバーフローチェックはやんなくていいって言ってる人の頭の中ってどうなってるのかな?
オーバーフローに関してだけはプログラムが完璧に作られてるからありえないって思想?

**デフォルトの名無しさん** · 2025/10/14(火) 00:26:24.96

実際の利用で最も多いシーケンシャルアクセスはインデックスの範囲チェックを消すことができる

for (i=start; i<end; i++) { a[i]利用 }
これはループ内でiの終端チェックとa[i]の範囲チェックの2回起きる

for (p=&a[start]; p<&a[end]; p++) { *p利用 }
このように書くかもしくはコンパイラが取り扱うと
ループ内でpの終端チェックのみになる
しかし人間が行なうとミスが入り込む余地があるため好ましくない

Rustなどはこれを抽象的なイテレータとして提供していて抽象化とメモリ安全性と実行効率の三つを両立させている

**デフォルトの名無しさん** · 2025/10/14(火) 01:29:56.77

配列は静的メモリ確保なのに動的メモリ確保とごっちゃになっている素人w

**デフォルトの名無しさん** · 2025/10/14(火) 01:39:29.82

>>316
言語によって細かい区別や呼び方から実装方法まで様々に異なるため
こういう時に皆は抽象的に代表名として配列と呼んでいるだけだよ

その意味での配列を静的メモリ領域に置くこともあればスタック領域に動的に置くこともあればビープ領域に動的に置くこともある
そして静的であろうと動的であろうと場所がどこであろうと範囲チェックは必要

**デフォルトの名無しさん** · 2025/10/14(火) 05:15:51.00

>>316
配列を必ず静的に確保する言語はレア
多くの言語は配列を宣言する位置によって動的確保がある

例えばC言語は関数内で配列を宣言すると関数呼び出しするたびに動的に配列を含めたローカル変数の領域がスタック上に自動的に確保される
静的確保ではなく動的確保であるからこそ関数の再帰呼び出しが可能になっている

**デフォルトの名無しさん** · 2025/10/14(火) 07:20:27.59

くっだらねえ

**デフォルトの名無しさん** · 2025/10/14(火) 15:07:30.93

>>316
静的メモリ確保の意味を理解できてないだろ
Cならグローバル変数とstatic変数が静的メモリ領域に確保される
配列もグローバル変数かstatic変数にした時のみ静的メモリ確保
そうでない普通の関数内の配列は動的メモリ確保

**デフォルトの名無しさん** · 2025/10/14(火) 20:36:41.72

>>320
CやRustだと「普通の関数内の配列」にはスタックに置かれるものもあるんですが
要素数はコンパイル時に決まってる必要はあるけど

**デフォルトの名無しさん** · 2025/10/14(火) 21:04:55.21

>>321
違いは簡単
静的メモリ配置　←アドレス固定
動的メモリ配置　←アドレス変動

static宣言すると静的にメモリ領域が確保されてアドレスが固定になる
実例コード

void foo() {
static int a1[] = {1, 2, 3};
int a2[] = {1, 2, 3};
printf("アドレス固定 a1: %p\n", &a1);
printf("アドレス変動 a2: %p\n", &a2);
}

void sub() {
foo();
}

int main() {
foo();
sub();
return 0;
}