Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次1-新
327: 2025/10/15(水)19:23 ID:MHowvYgL(1) AAS
Grokに訊いたら非標準のallocaやC99のVLAは動的確保に含まれる場合があるそうだ。
328(1): 2025/10/15(水)19:43 ID:zk4Ust74(1) AAS
配列やベクタやリストやスライスなど、言語によって様々な呼び方や実装が異なるもの、全てに共通の必須な仕組みとして、
総称としての配列の範囲チェックの話をしていて、そのまま特定の言語に関係なくこの話の流れでいいんだよな
>>316
>>配列は静的メモリ確保なのに動的メモリ確保とごっちゃになっている素人w
静的と動的は様々な対象に用いられるが、今回は静的メモリ確保
これをアドレスが変わらないという解釈でも、いわゆるセグメントのうち静的領域に確保するという意味でも同じ
特定の言語の話ではないが、例えばC言語なら静的宣言(static宣言)をする変数がこれに該当する
動的メモリ領域は毎回アドレスが変わるという意味でも、何かをするたびにメモリ空間から領域を確保する意味でも同じ
ただし二つに分かれて、関数呼び出しのたびに領域が確保されて関数から去ると無効になるものと、関数呼び出しのタイミングと関係なく確保することで関数を去っても有効になるもの、それら二つの異なる性質のものに分かれる
いわゆるセグメント領域としては、前者はスタック領域に確保されて後者はヒープ領域に確保される
省1
329(1): 2025/10/15(水)22:57 ID:dwkfuJij(1/5) AAS
>>317
コレクションという言葉を知らないのか？
配列は連続したメモリ領域だぞ？
330(1): 2025/10/15(水)23:01 ID:dwkfuJij(2/5) AAS
>>320
あのさ、関数でも関数を呼び出す方でも実行時にメモリを確保するんだよ？
実行中にメモリを確保することは、また別の話。
331(1): 2025/10/15(水)23:03 ID:dwkfuJij(3/5) AAS
>>328
CPUとOSレベルで別のプロセスが使っているメモリ領域にアクセスできないようになっていることを知らない高齢者か？
進化を知らずに大昔の仕様で語るのはやめろ。
332(1): 2025/10/15(水)23:14 ID:1UpfUBnV(1/2) AAS
連投が全て的外れでワロタ
>>329
元レスはコレクションとも連続領域とも全く無関係な話だな
>>330
区別ついてないのかよ
静的な変数が置かれる静的領域は関数呼び出しと無関係に最初から存在するため遅くとも実行開始時点でアドレスが確定する
>>331
元レスに別プロセスの話もアクセス権もどこにも書かれてなく無関係
そもそもプロセス間の共有メモリがある
333(2): 2025/10/15(水)23:26 ID:dwkfuJij(4/5) AAS
>>332
元はメモリのアドレスをなめる行為の話だぞ？
飛び飛びのメモリ領域のことを一般的には配列とは呼ばない。コレクションの実装は飛び飛びのこともある。
334: 2025/10/15(水)23:27 ID:dwkfuJij(5/5) AAS
このスレはキータだったなw
変なやつしかいない
335: 2025/10/15(水)23:37 ID:1UpfUBnV(2/2) AAS
>>333
コレクションの話なんかどこにも出てきていないのに妄想で幻で見えてるのか？
336: 2025/10/15(水)23:46 ID:NrKjLOWm(1) AAS
>>333
飛び飛びのメモリ領域の話をしてる人はいないと思いますよ
どうして突然そんなことを言い出すのですか？
337: 2025/10/18(土)11:07 ID:bVsQMdfb(1/3) AAS
『浮動小数点数に非常に小さい値を加えるとどうなるか？float型の精度限界を調べた』
知識がないところでFLT_EPSILONに近い概念を独自に発見しようとしてるのは偉いのだが、deltafの初期値を0.1fで始めてるのが惜しい。1.0fにしてればFLT_EPSILONの1/2が求まる筈。
338(1): 2025/10/18(土)12:49 ID:bVsQMdfb(2/3) AAS
>>279
> オーバーフローチェックのコストはとんでもなく高いんだよ。
> 劇的に遅くなることが判っているよ。
簡単なコードで確認してみた。
外部ﾘﾝｸ:wandbox.org
339: 2025/10/18(土)13:32 ID:qBI4ZXTO(1) AAS
>>338 は32bitと大き目で更にoverflowしたらループを抜けるだけで代わりの値を代入したりしてない
unsigned charの8bit演算でoverflowしたら255にして
何回か毎に大きな値を引く(underflowは0)にする処理もあわせると分岐予測がある程度阻害されるのでは
(>>279 の具体的根拠は知らないけど)
340: 2025/10/18(土)13:44 ID:NqvbaKoR(1) AAS
＞32bitと大き目で更にoverflowしたらループを抜けるだけで代わりの値を代入したりしてない
1から4を1億回足してるだけだからオーバーフローは発生しない。>>279が問題にしてるのはオーバーフローチェックのコストでありオーバーフローするかどうかは関係がない。
341: 2025/10/18(土)19:06 ID:ETv7F4p1(1) AAS
実際のプログラムには足し算など無数にあるから分岐が無数に増えて分岐予測テーブルが溢れそう
342: 2025/10/18(土)19:11 ID:usFOY54p(1) AAS
Qiitaの話を全くしてないのは草
343: 2025/10/18(土)20:38 ID:wTbxZHCN(1) AAS
現実的には関数呼出になるから遅い…が、使いどころなんてたかが知れてるよな
344: 2025/10/18(土)20:49 ID:rM2qmS8P(1) AAS
結局こういうことだろね
現実と対応
303 デフォルトの名無しさん sage 2025/10/13(月) 02:39:47.42 ID:5mcGe2/B
オーバーフローのチェックのコストの重さ問題は特定の言語に関係なく全ての言語で生じる話だよ
そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ
そして必要に応じてオーバーフローのチェックをする関数を呼び出すなどして対応するよ
345: 2025/10/18(土)22:24 ID:bVsQMdfb(3/3) AAS
> そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ
危険を承知で`-Ounchecked`を指定しない限りオーバーフローチェックを行うSwiftが安全性については唯一まともな判断してるってことだよなあ。
外部ﾘﾝｸ:godbolt.org
346: 2025/10/18(土)22:43 ID:eyj6w4mM(1) AAS
半開区間を長い左右非対称な記号で表わす話もSwiftが異端だったな
そこまでの行き過ぎた過剰を他の言語は求めていないのだと思われる
上下前次1-新書関写板覧索設栞歴
あと 422 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s