Qiita 7 - キータぞ、来たぞ、キータだぞー (773ﾚｽ)
Qiita 7 - キータぞ、来たぞ、キータだぞー http://mevius.5ch.io/test/read.cgi/tech/1757733847/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
267: デフォルトの名無しさん [sage] 2025/10/10(金) 08:25:59.69 ID:ckTDD7bx 組み込みの世界知らない人かな http://mevius.5ch.io/test/read.cgi/tech/1757733847/267
268: デフォルトの名無しさん [] 2025/10/10(金) 09:05:26.07 ID:FYVFXot6 C以外は特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人って事? http://mevius.5ch.io/test/read.cgi/tech/1757733847/268
269: デフォルトの名無しさん [sage] 2025/10/10(金) 09:11:11.73 ID:9zFqUBbx >>267 それはコレやね >>特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ http://mevius.5ch.io/test/read.cgi/tech/1757733847/269
270: デフォルトの名無しさん [sage] 2025/10/10(金) 09:17:04.99 ID:JrlTg/8e >>268 C以外に未定義動作だらけなクソ言語あるの？ http://mevius.5ch.io/test/read.cgi/tech/1757733847/270
271: デフォルトの名無しさん [sage] 2025/10/10(金) 09:30:05.88 ID:ckTDD7bx > C以外に未定義動作だらけなクソ言語あるの？ C++も聞いたことない人かあ http://mevius.5ch.io/test/read.cgi/tech/1757733847/271
272: デフォルトの名無しさん [sage] 2025/10/10(金) 10:03:41.96 ID:Joie9IL1 C/C++は同罪だね C++が失敗した理由はいくつも挙げられてきたけど 拡張方法の失敗に加えてCの未定義動作を埋めきれなかったことが響いてる http://mevius.5ch.io/test/read.cgi/tech/1757733847/272
273: デフォルトの名無しさん [] 2025/10/10(金) 10:10:16.74 ID:EYYPWczZ Javaでもメソッド無いの初期化されていない変数とかで失敗するけど 未定義動作になるのを言語のせいとか言ってるけど自分が必用な値が自動でセットされるわけじゃないのだからそういう奴ってバグを作り出す http://mevius.5ch.io/test/read.cgi/tech/1757733847/273
274: デフォルトの名無しさん [sage] 2025/10/10(金) 10:23:29.55 ID:c258Qk98 >>273 Javaでは未定義動作にならないため問題は起きません ローカル変数は初期化しないとエラー インスタンス変数はデフォルト値で自動的に初期化されます デフォルト値は各型により0やfalseやnullなど定まっています Cの実行するたびに値が変わる問題はJavaでは起きません http://mevius.5ch.io/test/read.cgi/tech/1757733847/274
275: デフォルトの名無しさん [sage] 2025/10/10(金) 12:28:43.96 ID:ckTDD7bx 最適化のなしかありかで挙動の変わる言語があるらしいけどそういうのは最悪。 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); } http://mevius.5ch.io/test/read.cgi/tech/1757733847/275
276: デフォルトの名無しさん [sage] 2025/10/10(金) 12:45:31.67 ID:AslPjXj+ その辺見越して大きい値扱える変数使って明示的にうまいことやるからどうでもいいんだよなあ http://mevius.5ch.io/test/read.cgi/tech/1757733847/276
277: デフォルトの名無しさん [sage] 2025/10/10(金) 12:56:29.02 ID:BIOy5Wv+ >>275 debug modeとrelease modeの違い 標準状態ではdebug modeで動作 実行時コストをかけて様々な検出をしてくれる release modeでは明示的な実行時コスト指定ex. checked_add()などがある時のみ http://mevius.5ch.io/test/read.cgi/tech/1757733847/277
278: デフォルトの名無しさん [sage] 2025/10/10(金) 17:34:11.75 ID:ckTDD7bx x86やARMでオーバーフローチェックのコストなんて大したものではないので、最適化有効の場合でもオーバーフローチェックは行うのがフェイルセーフ的に正しいな。 オーバーフローチェックのコストが問題になるレアケースでは記述を変える対応が良い。 そういう判断できなかった辺りが残念言語なんだよなあ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/278
279: デフォルトの名無しさん [sage] 2025/10/10(金) 19:59:29.06 ID:EwscZStB >>278 オーバーフローチェックのコストはとんでもなく高いんだよ。 演算命令1つ行なう毎に、そこで立った条件フラグによる条件分岐を毎回行なう必要がある。 これはコンパイラが行なうコードの並べ替えやループの展開やベクトル化などを全て阻止してしまう。 劇的に遅くなることが判っているよ。 さらにアセンブリ言語を書いたりコンパイル結果を見たりしたことがあれば理解しやすいけど、 条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。 そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。 常にオーバーフローフラグを必要とするならそれもできなくなってしまう。 条件フラグをレジスタやメモリに一時退避させるコストもかかってくるんだよ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/279
280: デフォルトの名無しさん [sage] 2025/10/10(金) 21:05:08.50 ID:ckTDD7bx いまどきのプロセッサは分岐予測も優秀だし分岐しない条件分岐命令は大してペナルティならねぇよアホか。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/280
281: デフォルトの名無しさん [sage] 2025/10/10(金) 21:12:19.16 ID:ckTDD7bx ＞条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。 ＞そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。 知らないこと想像で書いてて大変宜しいｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/281
282: デフォルトの名無しさん [sage] 2025/10/10(金) 21:29:12.39 ID:EwscZStB >>280 理解できていないようだけど、 演算命令の順序が固定かつシリアル化されてしまうことが大きいんだよ。 命令順序の入れ替えは最適化の基幹であるとともに、並列展開もできなくなってしまう。 さらに条件フラグの保存コスト問題も生じてしまう。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/282
283: デフォルトの名無しさん [sage] 2025/10/10(金) 21:32:04.92 ID:EwscZStB >>281 x86など使ったことある人には常識だけど、 条件フラグの更新を伴う加算と伴わない加算としてADD命令とLEA命令の使い分けをコンパイラも多用しているよ。 それ以前の演算で反映された条件フラグを変化させないまま、 LEA命令によって加算や一部の乗算及びその組み合わせ演算をできる利点があるためだよ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/283
284: デフォルトの名無しさん [sage] 2025/10/10(金) 23:12:50.77 ID:ckTDD7bx 実例挙げられない辺りが限界なんだろうなあｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/284
285: デフォルトの名無しさん [sage] 2025/10/10(金) 23:19:18.23 ID:EwscZStB >>284 実例を既に>>283で挙げたよ。 もしかしてアセンブラ使ったことすらなくて理解すらできなかった？ http://mevius.5ch.io/test/read.cgi/tech/1757733847/285
286: デフォルトの名無しさん [sage] 2025/10/10(金) 23:42:12.34 ID:SqpOO1WH どのコンパイラがどういうコード吐いてるかも示せないで実例とか言ってるのはたまげたなｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/286
287: デフォルトの名無しさん [sage] 2025/10/11(土) 00:12:43.19 ID:e8fGXa5a ADDではなくLEAでフラグ変化させずに加算演算するのは手動でもコンパイラでも基本 この常識を理解できない低レベルな人はコード書いたりコンパイラ生成コードを見たことすらない人 http://mevius.5ch.io/test/read.cgi/tech/1757733847/287
288: デフォルトの名無しさん [sage] 2025/10/11(土) 10:05:05.53 ID:mX/iHQDj コンパイラが出力した「条件フラグを変更せず保持したまま演算を行なう」コードの実例から逃げてるとこ見ると「LEAで加算ができる」が知識の限界の人かな http://mevius.5ch.io/test/read.cgi/tech/1757733847/288
289: デフォルトの名無しさん [] 2025/10/11(土) 10:12:37.71 ID:mX/iHQDj > コンパイラ生成コードを見たことすらない人 このスレでCompiler Explorerのアドレス貼ってる人は珍しくないので（>>150とか）同様にして見せてやれば良い。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/289
290: デフォルトの名無しさん [sage] 2025/10/12(日) 03:13:55.78 ID:obnnOjq+ Rust信者ってこんなもんだなあとういうのはまあ納得 http://mevius.5ch.io/test/read.cgi/tech/1757733847/290
291: デフォルトの名無しさん [sage] 2025/10/12(日) 03:35:45.68 ID:Iv4aWOmO Rust？ 関係ないだろ http://mevius.5ch.io/test/read.cgi/tech/1757733847/291
292: デフォルトの名無しさん [] 2025/10/12(日) 05:25:08.36 ID:D80drn0C マシン語にするプログラミング言語は最適化によって意図と違うコードになることがあるという話をしたいんだろ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/292
293: デフォルトの名無しさん [sage] 2025/10/12(日) 12:59:12.78 ID:EE9svh1n > Rust？ > 関係ないだろ >>275からの話の流れが理解できない人かな http://mevius.5ch.io/test/read.cgi/tech/1757733847/293
294: デフォルトの名無しさん [sage] 2025/10/12(日) 19:07:27.09 ID:txsY3oX4 >>275 このRustプログラムが最適化あり（リリースビルド）／最適化なし（デバッグビルド）で挙動が変わる理由は、i8型の符号付き整数オーバーフローの扱い方が状況によって異なるためです 最適化なし（デバッグビルド） sum += numで加算の結果がi8の範囲（-128～127）を超えてしまうと、panicになるため意図した出力が得られず、エラーが発生します 最適化あり（リリースビルド） オーバーフローのチェックが省略されて二の補数によるラップアラウンド（桁あふれの結果として範囲内に収める計算）が行われます http://mevius.5ch.io/test/read.cgi/tech/1757733847/294
295: デフォルトの名無しさん [sage] 2025/10/12(日) 19:15:49.53 ID:txsY3oX4 リリースビルド（最適化あり）でもオーバーフローを検出し、デバッグビルド（最適化なし）と同じ挙動にする方法があります Cargo.tomlに以下を追記します： [profile.release] overflow-checks = true リリースビルドでも整数オーバーフローが発生するとpanic（異常終了）になります http://mevius.5ch.io/test/read.cgi/tech/1757733847/295
296: デフォルトの名無しさん [sage] 2025/10/12(日) 20:41:41.77 ID:VrekPvIE デフォで安全側に倒してない時点で残念言語だな http://mevius.5ch.io/test/read.cgi/tech/1757733847/296
297: デフォルトの名無しさん [sage] 2025/10/12(日) 21:03:27.80 ID:UHx3WDzt オーバーフローでプログラムを中断したいのか オーバーフローをエラーとして返したいのか オーバーフローを値として受けて活用したいのか オーバーフローは影響しない処理なのか 一般的に様々な状況が考えられる これは安全性の問題とは関係がない http://mevius.5ch.io/test/read.cgi/tech/1757733847/297
298: デフォルトの名無しさん [sage] 2025/10/12(日) 21:59:02.37 ID:VrekPvIE > オーバーフローでプログラムを中断したいのか > オーバーフローをエラーとして返したいのか > オーバーフローを値として受けて活用したいのか > オーバーフローは影響しない処理なのか > 一般的に様々な状況が考えられる 話についてこれない人かな http://mevius.5ch.io/test/read.cgi/tech/1757733847/298
299: デフォルトの名無しさん [sage] 2025/10/12(日) 22:06:32.37 ID:UHx3WDzt >>298 オーバーフローをどう処理したいかはプログラミングの内容に依って変わる これは安全性の問題ではない http://mevius.5ch.io/test/read.cgi/tech/1757733847/299
300: デフォルトの名無しさん [sage] 2025/10/12(日) 22:47:47.29 ID:EE9svh1n オーバーフローを無視して処理を続けていいわけはないので安全性の話なんだよなあ 何言ってんのこの人ｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/300
301: デフォルトの名無しさん [sage] 2025/10/12(日) 22:55:53.45 ID:jaSkqZ+M オーバーフローは無視できる処理もあるし、オーバーフローが起きない場合もあるわけだから、そこはケースバイケースやろ。 状況次第としか。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/301
302: デフォルトの名無しさん [sage] 2025/10/12(日) 23:07:39.13 ID:yC0+QvH7 生成コードで考えると オーバーフローフラグが立つ演算命令1つ毎に直後にオーバーフローの有無で判断する分岐命令を必ず入れることになるがそれは効率が悪すぎる しかも命令順序の固定化と直列化を招いてしまう 現在のCPUは命令順序の入れ替えと並列化で最適化をするからそれができないと劇的に遅くなる 不要なオーバーフローチェックは可能な限り避けるべき http://mevius.5ch.io/test/read.cgi/tech/1757733847/302
303: デフォルトの名無しさん [sage] 2025/10/13(月) 02:39:47.42 ID:5mcGe2/B >>290 オーバーフローのチェックのコストの重さ問題は特定の言語に関係なく全ての言語で生じる話だよ そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ そして必要に応じてオーバーフローのチェックをする関数を呼び出すなどして対応するよ http://mevius.5ch.io/test/read.cgi/tech/1757733847/303
304: デフォルトの名無しさん [sage] 2025/10/13(月) 02:43:31.43 ID:eGOGeFhV 最適化のなしかありかで挙動の変わると言ったのが間違い 最適化でなくオーバーフローチェックのなしかありかで挙動の変わる デフォで安全側に倒してないと言ったのも間違いでデフォでデバッグビルドを作って安全側に倒してオーバーフローチェックがある 劇的に遅くなるからリリースビルドのデフォでオーバーフローチェックがないのは妥当 http://mevius.5ch.io/test/read.cgi/tech/1757733847/304
305: デフォルトの名無しさん [sage] 2025/10/13(月) 09:36:39.69 ID:wFHYv9H9 配列アクセスで範囲チェックしてくれる言語についてオーバーフローチェックは「効率ｶﾞｰ」と発狂してるのｵﾓﾛｲｗ お前らRustも実行効率もなんも分かってないなｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/305
306: デフォルトの名無しさん [sage] 2025/10/13(月) 16:43:07.06 ID:4KhFq0Un 配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項 コンパイラが範囲内であると判断できれば最適化で安全にチェックをなくすことが可能 さらにRustなどではシーケンシャルアクセスの場合にインデックスアクセスが使われないため安全性と実行効率を両立させている http://mevius.5ch.io/test/read.cgi/tech/1757733847/306
307: デフォルトの名無しさん [sage] 2025/10/13(月) 22:59:28.18 ID:CEh/Jf9d > 配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項 オーバーフローチェックをやんなくて良い理由なんてないし。 > コンパイラが範囲内であると判断できれば最適化で安全にチェックをなくすことが可能 それはオーバーフローチェックも同様。>>275のコードなんてコンパイル時にオーバーフローするか判定できるわけだし。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/307
308: デフォルトの名無しさん [sage] 2025/10/13(月) 23:06:55.10 ID:KxydRFf5 ＞配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項 プログラムが完璧に作られてれば範囲チェックなんて要らんぞ？何言ってんの？？ http://mevius.5ch.io/test/read.cgi/tech/1757733847/308
309: デフォルトの名無しさん [sage] 2025/10/13(月) 23:21:03.25 ID:cZNgUw0p >>308 本気で言ってるのかね？ 範囲外アクセスでどれだけ多くのセキュリティホールを招いてきているか http://mevius.5ch.io/test/read.cgi/tech/1757733847/309
310: デフォルトの名無しさん [sage] 2025/10/13(月) 23:38:05.02 ID:xSeTVBuE 配列などのメモリ範囲外アクセスチェックは必ずしなければならない。 その上でコンパイラが範囲内だと保証できれば最適化により範囲内チェックを省略する。 ミスを起こし得る人間がそれを判断してはいけない。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/310
311: デフォルトの名無しさん [sage] 2025/10/14(火) 00:00:34.05 ID:EH8FowVD Cで配列などのメモリ範囲外アクセスチェックは必ずするかと言ったらしないよね？ 「必ず」というのはそれを必ずするライブラリを使うということで フリーの配列ライブラリなんてないよね？ 配列ライブラリを使うならRustでいいと http://mevius.5ch.io/test/read.cgi/tech/1757733847/311
312: デフォルトの名無しさん [sage] 2025/10/14(火) 00:04:17.51 ID:a2UJ2nPa >>311 そのためにC/C++は大量のセキュリティホールを生み出してきた そんなことは許されない時代になった C/C++はそれ以外にも多くの未定義動作など問題が多すぎるため使うべきではない http://mevius.5ch.io/test/read.cgi/tech/1757733847/312
313: デフォルトの名無しさん [sage] 2025/10/14(火) 00:14:41.04 ID:lAetg0vq 「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「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/ http://mevius.5ch.io/test/read.cgi/tech/1757733847/313
314: デフォルトの名無しさん [sage] 2025/10/14(火) 00:14:44.98 ID:sCKwxfM0 配列アクセスでの範囲チェックは絶対必要だけどオーバーフローチェックはやんなくていいって言ってる人の頭の中ってどうなってるのかな? オーバーフローに関してだけはプログラムが完璧に作られてるからありえないって思想? http://mevius.5ch.io/test/read.cgi/tech/1757733847/314
315: デフォルトの名無しさん [sage] 2025/10/14(火) 00:26:24.96 ID:JKaSUvhP 実際の利用で最も多いシーケンシャルアクセスはインデックスの範囲チェックを消すことができる for (i=start; i<end; i++) { a[i]利用 } これはループ内でiの終端チェックとa[i]の範囲チェックの2回起きる for (p=&a[start]; p<&a[end]; p++) { *p利用 } このように書くかもしくはコンパイラが取り扱うと ループ内でpの終端チェックのみになる しかし人間が行なうとミスが入り込む余地があるため好ましくない Rustなどはこれを抽象的なイテレータとして提供していて抽象化とメモリ安全性と実行効率の三つを両立させている http://mevius.5ch.io/test/read.cgi/tech/1757733847/315
316: デフォルトの名無しさん [] 2025/10/14(火) 01:29:56.77 ID:QdU4k/SE 配列は静的メモリ確保なのに動的メモリ確保とごっちゃになっている素人w http://mevius.5ch.io/test/read.cgi/tech/1757733847/316
317: デフォルトの名無しさん [sage] 2025/10/14(火) 01:39:29.82 ID:gE5nGyvL >>316 言語によって細かい区別や呼び方から実装方法まで様々に異なるため こういう時に皆は抽象的に代表名として配列と呼んでいるだけだよ その意味での配列を静的メモリ領域に置くこともあればスタック領域に動的に置くこともあればビープ領域に動的に置くこともある そして静的であろうと動的であろうと場所がどこであろうと範囲チェックは必要 http://mevius.5ch.io/test/read.cgi/tech/1757733847/317
318: デフォルトの名無しさん [sage] 2025/10/14(火) 05:15:51.00 ID:vZAfdOxe >>316 配列を必ず静的に確保する言語はレア 多くの言語は配列を宣言する位置によって動的確保がある 例えばC言語は関数内で配列を宣言すると関数呼び出しするたびに動的に配列を含めたローカル変数の領域がスタック上に自動的に確保される 静的確保ではなく動的確保であるからこそ関数の再帰呼び出しが可能になっている http://mevius.5ch.io/test/read.cgi/tech/1757733847/318
319: デフォルトの名無しさん [sage] 2025/10/14(火) 07:20:27.59 ID:dimV1O2B くっだらねえ http://mevius.5ch.io/test/read.cgi/tech/1757733847/319
320: デフォルトの名無しさん [sage] 2025/10/14(火) 15:07:30.93 ID:vn+4DI+D >>316 静的メモリ確保の意味を理解できてないだろ Cならグローバル変数とstatic変数が静的メモリ領域に確保される 配列もグローバル変数かstatic変数にした時のみ静的メモリ確保 そうでない普通の関数内の配列は動的メモリ確保 http://mevius.5ch.io/test/read.cgi/tech/1757733847/320
321: デフォルトの名無しさん [] 2025/10/14(火) 20:36:41.72 ID:2xWEVdNj >>320 CやRustだと「普通の関数内の配列」にはスタックに置かれるものもあるんですが 要素数はコンパイル時に決まってる必要はあるけど http://mevius.5ch.io/test/read.cgi/tech/1757733847/321
322: デフォルトの名無しさん [sage] 2025/10/14(火) 21:04:55.21 ID:ZulSE3F6 >>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; } http://mevius.5ch.io/test/read.cgi/tech/1757733847/322
323: デフォルトの名無しさん [] 2025/10/15(水) 01:32:24.83 ID:F/Bk7x58 >>316 >>321 staticの意味は「静的な」 staticを付けないと動的に毎回確保されることくらい分かりそうなものだが http://mevius.5ch.io/test/read.cgi/tech/1757733847/323
324: デフォルトの名無しさん [sage] 2025/10/15(水) 02:42:55.78 ID:tBMKGpTr なんてことだstatic宣言した変数が共有ライブラリの中だとアドレスが変わることがあるゾ！ http://mevius.5ch.io/test/read.cgi/tech/1757733847/324
325: デフォルトの名無しさん [sage] 2025/10/15(水) 02:49:12.17 ID:LnEbzNuN >>324 リンク時に変わることはあっても 実行中にアドレスが変わることはない http://mevius.5ch.io/test/read.cgi/tech/1757733847/325
326: デフォルトの名無しさん [sage] 2025/10/15(水) 18:27:52.24 ID:V1g0382z cの静的動的はサイズが実行時に定まるか否かってことじゃないん？ staticかどうかはcプログラマにとっては別の感心事で メモリの動静を語るときはそうだったと思うけど 俺の知ってる限り staticつけてないローカルな配列のことを動的な確保って言ってる人見たこと無いわ http://mevius.5ch.io/test/read.cgi/tech/1757733847/326
327: デフォルトの名無しさん [sage] 2025/10/15(水) 19:23:40.95 ID:MHowvYgL Grokに訊いたら非標準のallocaやC99のVLAは動的確保に含まれる場合があるそうだ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/327
328: デフォルトの名無しさん [sage] 2025/10/15(水) 19:43:01.58 ID:zk4Ust74 配列やベクタやリストやスライスなど、言語によって様々な呼び方や実装が異なるもの、全てに共通の必須な仕組みとして、 総称としての配列の範囲チェックの話をしていて、そのまま特定の言語に関係なくこの話の流れでいいんだよな >>316 >>配列は静的メモリ確保なのに動的メモリ確保とごっちゃになっている素人w 静的と動的は様々な対象に用いられるが、今回は静的メモリ確保 これをアドレスが変わらないという解釈でも、いわゆるセグメントのうち静的領域に確保するという意味でも同じ 特定の言語の話ではないが、例えばC言語なら静的宣言(static宣言)をする変数がこれに該当する 動的メモリ領域は毎回アドレスが変わるという意味でも、何かをするたびにメモリ空間から領域を確保する意味でも同じ ただし二つに分かれて、関数呼び出しのたびに領域が確保されて関数から去ると無効になるものと、関数呼び出しのタイミングと関係なく確保することで関数を去っても有効になるもの、それら二つの異なる性質のものに分かれる いわゆるセグメント領域としては、前者はスタック領域に確保されて後者はヒープ領域に確保される 前述の静的領域の変数とは異なり、スタック領域やヒープ領域に動的に確保することが共通の特徴であり、タイミングによってアドレスも変化する http://mevius.5ch.io/test/read.cgi/tech/1757733847/328
329: デフォルトの名無しさん [] 2025/10/15(水) 22:57:25.39 ID:dwkfuJij >>317 コレクションという言葉を知らないのか？ 配列は連続したメモリ領域だぞ？ http://mevius.5ch.io/test/read.cgi/tech/1757733847/329
330: デフォルトの名無しさん [] 2025/10/15(水) 23:01:05.50 ID:dwkfuJij >>320 あのさ、関数でも関数を呼び出す方でも実行時にメモリを確保するんだよ？ 実行中にメモリを確保することは、また別の話。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/330
331: デフォルトの名無しさん [] 2025/10/15(水) 23:03:30.96 ID:dwkfuJij >>328 CPUとOSレベルで別のプロセスが使っているメモリ領域にアクセスできないようになっていることを知らない高齢者か？ 進化を知らずに大昔の仕様で語るのはやめろ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/331
332: デフォルトの名無しさん [sage] 2025/10/15(水) 23:14:46.54 ID:1UpfUBnV 連投が全て的外れでワロタ >>329 元レスはコレクションとも連続領域とも全く無関係な話だな >>330 区別ついてないのかよ 静的な変数が置かれる静的領域は関数呼び出しと無関係に最初から存在するため遅くとも実行開始時点でアドレスが確定する >>331 元レスに別プロセスの話もアクセス権もどこにも書かれてなく無関係 そもそもプロセス間の共有メモリがある http://mevius.5ch.io/test/read.cgi/tech/1757733847/332
333: デフォルトの名無しさん [] 2025/10/15(水) 23:26:49.61 ID:dwkfuJij >>332 元はメモリのアドレスをなめる行為の話だぞ？ 飛び飛びのメモリ領域のことを一般的には配列とは呼ばない。コレクションの実装は飛び飛びのこともある。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/333
334: デフォルトの名無しさん [] 2025/10/15(水) 23:27:17.68 ID:dwkfuJij このスレはキータだったなw 変なやつしかいない http://mevius.5ch.io/test/read.cgi/tech/1757733847/334
335: デフォルトの名無しさん [sage] 2025/10/15(水) 23:37:23.88 ID:1UpfUBnV >>333 コレクションの話なんかどこにも出てきていないのに妄想で幻で見えてるのか？ http://mevius.5ch.io/test/read.cgi/tech/1757733847/335
336: デフォルトの名無しさん [sage] 2025/10/15(水) 23:46:08.93 ID:NrKjLOWm >>333 飛び飛びのメモリ領域の話をしてる人はいないと思いますよ どうして突然そんなことを言い出すのですか？ http://mevius.5ch.io/test/read.cgi/tech/1757733847/336
337: デフォルトの名無しさん [sage] 2025/10/18(土) 11:07:29.35 ID:bVsQMdfb 『浮動小数点数に非常に小さい値を加えるとどうなるか？float型の精度限界を調べた』 知識がないところでFLT_EPSILONに近い概念を独自に発見しようとしてるのは偉いのだが、deltafの初期値を0.1fで始めてるのが惜しい。1.0fにしてればFLT_EPSILONの1/2が求まる筈。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/337
338: デフォルトの名無しさん [sage] 2025/10/18(土) 12:49:36.77 ID:bVsQMdfb >>279 > オーバーフローチェックのコストはとんでもなく高いんだよ。 > 劇的に遅くなることが判っているよ。 簡単なコードで確認してみた。 https://wandbox.org/permlink/L8hZILgJIhDYqDkB http://mevius.5ch.io/test/read.cgi/tech/1757733847/338
339: デフォルトの名無しさん [sage] 2025/10/18(土) 13:32:11.38 ID:qBI4ZXTO >>338 は32bitと大き目で更にoverflowしたらループを抜けるだけで代わりの値を代入したりしてない unsigned charの8bit演算でoverflowしたら255にして 何回か毎に大きな値を引く(underflowは0)にする処理もあわせると分岐予測がある程度阻害されるのでは (>>279 の具体的根拠は知らないけど) http://mevius.5ch.io/test/read.cgi/tech/1757733847/339
340: デフォルトの名無しさん [sage] 2025/10/18(土) 13:44:09.89 ID:NqvbaKoR ＞32bitと大き目で更にoverflowしたらループを抜けるだけで代わりの値を代入したりしてない 1から4を1億回足してるだけだからオーバーフローは発生しない。>>279が問題にしてるのはオーバーフローチェックのコストでありオーバーフローするかどうかは関係がない。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/340
341: デフォルトの名無しさん [sage] 2025/10/18(土) 19:06:57.05 ID:ETv7F4p1 実際のプログラムには足し算など無数にあるから分岐が無数に増えて分岐予測テーブルが溢れそう http://mevius.5ch.io/test/read.cgi/tech/1757733847/341
342: デフォルトの名無しさん [sage] 2025/10/18(土) 19:11:50.98 ID:usFOY54p Qiitaの話を全くしてないのは草 http://mevius.5ch.io/test/read.cgi/tech/1757733847/342
343: デフォルトの名無しさん [sage] 2025/10/18(土) 20:38:26.02 ID:wTbxZHCN 現実的には関数呼出になるから遅い…が、使いどころなんてたかが知れてるよな http://mevius.5ch.io/test/read.cgi/tech/1757733847/343
344: デフォルトの名無しさん [sage] 2025/10/18(土) 20:49:39.50 ID:rM2qmS8P 結局こういうことだろね 現実と対応 303 デフォルトの名無しさん sage 2025/10/13(月) 02:39:47.42 ID:5mcGe2/B オーバーフローのチェックのコストの重さ問題は特定の言語に関係なく全ての言語で生じる話だよ そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ そして必要に応じてオーバーフローのチェックをする関数を呼び出すなどして対応するよ http://mevius.5ch.io/test/read.cgi/tech/1757733847/344
345: デフォルトの名無しさん [sage] 2025/10/18(土) 22:24:24.75 ID:bVsQMdfb > そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ 危険を承知で`-Ounchecked`を指定しない限りオーバーフローチェックを行うSwiftが安全性については唯一まともな判断してるってことだよなあ。 https://godbolt.org/z/fMc6KdPb1 http://mevius.5ch.io/test/read.cgi/tech/1757733847/345
346: デフォルトの名無しさん [sage] 2025/10/18(土) 22:43:53.65 ID:eyj6w4mM 半開区間を長い左右非対称な記号で表わす話もSwiftが異端だったな そこまでの行き過ぎた過剰を他の言語は求めていないのだと思われる http://mevius.5ch.io/test/read.cgi/tech/1757733847/346
347: デフォルトの名無しさん [sage] 2025/10/18(土) 23:17:36.52 ID:63qoaJUs 最適化指示でオーバーフロー検出が働くなるRustの仕様が適当かはRustの開発コミュでもたびたび議論になってることなのに「現行がこうなってる」で納得してるのは思考停止なんだよなあ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/347
348: デフォルトの名無しさん [sage] 2025/10/18(土) 23:33:52.89 ID:3aakVM9g Rustはプロジェクトを作る時にオーバーフローのチェックを強制したい方針ならばこの指定機能が何年も前に入ったため今は大丈夫だよ overflow-checks = true http://mevius.5ch.io/test/read.cgi/tech/1757733847/348
349: デフォルトの名無しさん [sage] 2025/10/18(土) 23:42:20.50 ID:63qoaJUs >>348 そういうの気にしない馬鹿のためにデフォルトの挙動はどうであるべきかって話が理解できない奴は安全性について語らない方が良いよ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/349
350: デフォルトの名無しさん [sage] 2025/10/18(土) 23:49:49.42 ID:7LIpXt77 RustがIT各社に次々と採用されていってる理由は企業から見ても安全性が最も良い言語であると支持されたため http://mevius.5ch.io/test/read.cgi/tech/1757733847/350
351: デフォルトの名無しさん [sage] 2025/10/19(日) 20:21:17.40 ID:+RR12fUB 『🏆最小自由数で競う！C++, Lisp, Rust, Mojoによる速度対決🔥 / Competing on the Minimum Free Number! Speed Battle with C++, Lisp, Rust, and Mojo 🔥』 https://qiita.com/tj9999/items/4131016df5f1c5730584 「そのコードは良くない。こう書くべき」みたいな具体的なコメントができない辺りがRust信者の限界なのかな http://mevius.5ch.io/test/read.cgi/tech/1757733847/351
352: デフォルトの名無しさん [sage] 2025/10/20(月) 22:42:27.76 ID:RnZTjdTH このスレ見る限りRust信者はコード書けないみたいだしなあ http://mevius.5ch.io/test/read.cgi/tech/1757733847/352
353: デフォルトの名無しさん [sage] 2025/10/21(火) 15:24:12.70 ID:2uplBhQe > オーバーフローチェックのコストはとんでもなく高いんだよ。 > 劇的に遅くなることが判っているよ。 安全性よりパフォーマンスが重要と思ってる人は根本的なところから分かってない。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/353
354: デフォルトの名無しさん [sage] 2025/10/21(火) 16:11:44.43 ID:PAfcSIKV 安全重視のJavaもオーバーフローチェックしないよ http://mevius.5ch.io/test/read.cgi/tech/1757733847/354
355: デフォルトの名無しさん [sage] 2025/10/21(火) 16:42:19.08 ID:bG0rJrvl もはや誰もQiitaの話をしていないのである http://mevius.5ch.io/test/read.cgi/tech/1757733847/355
356: デフォルトの名無しさん [sage] 2025/10/21(火) 17:18:52.11 ID:2uplBhQe 30年前の設計のJavaを安全重視と信じてる人がいるとはたまげたなあ http://mevius.5ch.io/test/read.cgi/tech/1757733847/356
357: デフォルトの名無しさん [sage] 2025/10/21(火) 17:46:00.64 ID:d/sWvnzZ 最近の言語Go Nim RustなどもCやJavaと同様にデフォルトではオーバーフロー時にラップアラウンド http://mevius.5ch.io/test/read.cgi/tech/1757733847/357
358: デフォルトの名無しさん [sage] 2025/10/21(火) 18:39:21.79 ID:2uplBhQe > 最近の言語Go Nim RustなどもCやJavaと同様にデフォルトではオーバーフロー時にラップアラウンド C言語では符号付き整数のオーバーフローは未定義動作なんだがそんなことも知らない輩がなんか言ってなんだなあ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/358
359: デフォルトの名無しさん [sage] 2025/10/21(火) 19:12:50.27 ID:CCxWu0hF デフォルトでオーバーフローチェックしなくて問題になった話を聞いたことがないな 世の中のシステムは問題なく動いているもんな チェックしたければオーバーフローチェックできるから何が問題なのかわからん http://mevius.5ch.io/test/read.cgi/tech/1757733847/359
360: デフォルトの名無しさん [sage] 2025/10/21(火) 19:36:04.80 ID:2uplBhQe 255からエクステンドでゲームオーバーなんてザラにあるのにな http://mevius.5ch.io/test/read.cgi/tech/1757733847/360
361: デフォルトの名無しさん [sage] 2025/10/21(火) 23:13:46.96 ID:Xc9g4ZCw >>43 『VRでもリアル空間でもスマホでも！「sonoXR」での音楽体験を実現する先端技術・FPGA独自チップ』 https://note.com/mimylovesmusic/n/n0982c3323b50 ↑の記事で当日の様子が紹介されてる。 > そのElixirChipですが、2025年9月17日、Elixir関連コミュニティのオンラインLT会で初お披露目されました！ > LT会のデモンストレーションでは、macの画面共有でElixirChipがターミナルから実行されている処理が映し出されて、その解説がメインのお話だったのですよね。 > それもそのはず。 > FPGA（Field Programmable Gate Array）とは「内部の論理回路をソフトウェアのように後から自由に組み替えられるチップ」のことだというのを、このLT会で今更ながら理解しました。（お恥ずかしい・・・） > 私はElixirChipの開発を行う株式会社Digidock Consultingにてセールスエグゼクティブも担当しています。 FPGAがどういうもんだか知らなかった人がセールス担当で「先端技術・FPGA独自チップ」とか言ってんのスゲエな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/361
362: デフォルトの名無しさん [sage] 2025/10/21(火) 23:25:43.96 ID:Kzm3UPI2 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない http://mevius.5ch.io/test/read.cgi/tech/1757733847/362
363: デフォルトの名無しさん [] 2025/10/21(火) 23:37:30.32 ID:Xc9g4ZCw > 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない 2**64/(365.25*24*3600*10000000000) = 58.4542046091 だから59年目でオーバーフローするだろ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/363
364: デフォルトの名無しさん [sage] 2025/10/22(水) 00:52:52.35 ID:36Oigqe9 8bit時代は一瞬で溢れたのに 64bit時代は凄いな http://mevius.5ch.io/test/read.cgi/tech/1757733847/364
365: デフォルトの名無しさん [sage] 2025/10/22(水) 02:05:57.52 ID:1Zu7PCWv ５９年に1回だけ出現するバグがすごい 毎年再起動で対応すべき http://mevius.5ch.io/test/read.cgi/tech/1757733847/365
366: デフォルトの名無しさん [sage] 2025/10/22(水) 02:24:22.73 ID:W6apSoTE 最新のCPUでも10GHz行かないので1秒間に100億回のカウントが無理だよな オーバーフローするまでもっとかかる http://mevius.5ch.io/test/read.cgi/tech/1757733847/366
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 407 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.036s