Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次1-新
302: 2025/10/12(日)23:07 ID:yC0+QvH7(1) AAS
生成コードで考えると
オーバーフローフラグが立つ演算命令1つ毎に直後にオーバーフローの有無で判断する分岐命令を必ず入れることになるがそれは効率が悪すぎる
しかも命令順序の固定化と直列化を招いてしまう
現在のCPUは命令順序の入れ替えと並列化で最適化をするからそれができないと劇的に遅くなる
不要なオーバーフローチェックは可能な限り避けるべき
303: 2025/10/13(月)02:39 ID:5mcGe2/B(1) AAS
>>290
オーバーフローのチェックのコストの重さ問題は特定の言語に関係なく全ての言語で生じる話だよ
そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ
そして必要に応じてオーバーフローのチェックをする関数を呼び出すなどして対応するよ
304: 2025/10/13(月)02:43 ID:eGOGeFhV(1) AAS
最適化のなしかありかで挙動の変わると言ったのが間違い
最適化でなくオーバーフローチェックのなしかありかで挙動の変わる
デフォで安全側に倒してないと言ったのも間違いでデフォでデバッグビルドを作って安全側に倒してオーバーフローチェックがある
劇的に遅くなるからリリースビルドのデフォでオーバーフローチェックがないのは妥当
305: 2025/10/13(月)09:36 ID:wFHYv9H9(1) AAS
配列アクセスで範囲チェックしてくれる言語についてオーバーフローチェックは「効率ｶﾞｰ」と発狂してるのｵﾓﾛｲｗ
お前らRustも実行効率もなんも分かってないなｗ
306: 2025/10/13(月)16:43 ID:4KhFq0Un(1) AAS
配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項
コンパイラが範囲内であると判断できれば最適化で安全にチェックをなくすことが可能
さらにRustなどではシーケンシャルアクセスの場合にインデックスアクセスが使われないため安全性と実行効率を両立させている
307: 2025/10/13(月)22:59 ID:CEh/Jf9d(1) AAS
> 配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項
オーバーフローチェックをやんなくて良い理由なんてないし。
> コンパイラが範囲内であると判断できれば最適化で安全にチェックをなくすことが可能
それはオーバーフローチェックも同様。>>275のコードなんてコンパイル時にオーバーフローするか判定できるわけだし。
308(1): 2025/10/13(月)23:06 ID:KxydRFf5(1) AAS
＞配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項
プログラムが完璧に作られてれば範囲チェックなんて要らんぞ？何言ってんの？？
309: 2025/10/13(月)23:21 ID:cZNgUw0p(1) AAS
>>308
本気で言ってるのかね？
範囲外アクセスでどれだけ多くのセキュリティホールを招いてきているか
310: 2025/10/13(月)23:38 ID:xSeTVBuE(1) AAS
配列などのメモリ範囲外アクセスチェックは必ずしなければならない。
その上でコンパイラが範囲内だと保証できれば最適化により範囲内チェックを省略する。
ミスを起こし得る人間がそれを判断してはいけない。
311(1): 2025/10/14(火)00:00 ID:EH8FowVD(1) AAS
Cで配列などのメモリ範囲外アクセスチェックは必ずするかと言ったらしないよね？
「必ず」というのはそれを必ずするライブラリを使うということで
フリーの配列ライブラリなんてないよね？
配列ライブラリを使うならRustでいいと
312: 2025/10/14(火)00:04 ID:a2UJ2nPa(1) AAS
>>311
そのためにC/C++は大量のセキュリティホールを生み出してきた
そんなことは許されない時代になった
C/C++はそれ以外にも多くの未定義動作など問題が多すぎるため使うべきではない
313: 2025/10/14(火)00:14 ID:lAetg0vq(1) AAS
「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
外部ﾘﾝｸ[html]:atmarkit.itmedia.co.jp
米国ホワイトハウスが開発者に対しC++やC言語からRustやJavaなどのメモリ安全性に優れたプログラミング言語への移行を勧める
外部ﾘﾝｸ:gigazine.net
314: 2025/10/14(火)00:14 ID:sCKwxfM0(1) AAS
配列アクセスでの範囲チェックは絶対必要だけどオーバーフローチェックはやんなくていいって言ってる人の頭の中ってどうなってるのかな?
オーバーフローに関してだけはプログラムが完璧に作られてるからありえないって思想?
315: 2025/10/14(火)00:26 ID:JKaSUvhP(1) AAS
実際の利用で最も多いシーケンシャルアクセスはインデックスの範囲チェックを消すことができる
for (i=start; i<end; i++) { a[i]利用 }
これはループ内でiの終端チェックとa[i]の範囲チェックの2回起きる
for (p=&a[start]; p<&a[end]; p++) { *p利用 }
このように書くかもしくはコンパイラが取り扱うと
ループ内でpの終端チェックのみになる
しかし人間が行なうとミスが入り込む余地があるため好ましくない
Rustなどはこれを抽象的なイテレータとして提供していて抽象化とメモリ安全性と実行効率の三つを両立させている
316(5): 2025/10/14(火)01:29 ID:QdU4k/SE(1) AAS
配列は静的メモリ確保なのに動的メモリ確保とごっちゃになっている素人w
317(1): 2025/10/14(火)01:39 ID:gE5nGyvL(1) AAS
>>316
言語によって細かい区別や呼び方から実装方法まで様々に異なるため
こういう時に皆は抽象的に代表名として配列と呼んでいるだけだよ
その意味での配列を静的メモリ領域に置くこともあればスタック領域に動的に置くこともあればビープ領域に動的に置くこともある
そして静的であろうと動的であろうと場所がどこであろうと範囲チェックは必要
318: 2025/10/14(火)05:15 ID:vZAfdOxe(1) AAS
>>316
配列を必ず静的に確保する言語はレア
多くの言語は配列を宣言する位置によって動的確保がある
例えばC言語は関数内で配列を宣言すると関数呼び出しするたびに動的に配列を含めたローカル変数の領域がスタック上に自動的に確保される
静的確保ではなく動的確保であるからこそ関数の再帰呼び出しが可能になっている
319: 2025/10/14(火)07:20 ID:dimV1O2B(1) AAS
くっだらねえ
320(2): 2025/10/14(火)15:07 ID:vn+4DI+D(1) AAS
>>316
静的メモリ確保の意味を理解できてないだろ
Cならグローバル変数とstatic変数が静的メモリ領域に確保される
配列もグローバル変数かstatic変数にした時のみ静的メモリ確保
そうでない普通の関数内の配列は動的メモリ確保
321(2): 2025/10/14(火)20:36 ID:2xWEVdNj(1) AAS
>>320
CやRustだと「普通の関数内の配列」にはスタックに置かれるものもあるんですが
要素数はコンパイル時に決まってる必要はあるけど
上下前次1-新書関写板覧索設栞歴
あと 447 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.012s