Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次1-新
253(1): 2025/10/04(土)23:29 ID:gLEEZL45(1) AAS
>immutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
マイナーな言語しかなくね？
「そういう言語がある」だけで、多くの人にとってはそれが便利だと思われてないと思うぞ
254: 2025/10/04(土)23:33 ID:qAgFTJKW(1) AAS
Elixirの軽量スレッドで並列処理が効率化できてスパコン的用途にも使えると思ってる人たちだからなあ、つける薬がない。
255: 2025/10/04(土)23:59 ID:XZN99/my(1) AAS
>>253
immutableだけだと不便で制限が生じる
その一方でプログラムはなるべくimmutableを中心にしてmutableは補助的に使うと良いコードになる
256(1): 2025/10/05(日)23:10 ID:W6M3iXcI(1) AAS
Elixirでフィボナッチ数列をいろいろ書いてみた Part. 5
外部ﾘﾝｸ:qiita.com
> Fibonacci with Matrix は素晴らしく速いですね！
Elixirで順に指定個数の素数を列挙する関数をEnum, Stream, Flowで作ってみた
外部ﾘﾝｸ:qiita.com
> 1000,10000個の時にはFlowが最速でした．
1000番目のフィボナッチ数計算すんのに 1.33m秒とか、ベンチマーク結果なんでか編集で消えてるんだけど
> prime_flow 11.84 84.48 ms ±1.22% 84.27 ms 89.85 ms
20000未満の素数算出すんのに 84m秒って遅すぎね?
省1
257: 2025/10/05(日)23:41 AAS
スキルがあるのに福岡なんかにある仕事の給料で耐えられるわけない
258(1): 2025/10/06(月)00:44 ID:3OKVU+gM(1) AAS
>>256
> 20000未満の素数算出すんのに 84m秒って遅すぎね?
ベンチマーク出すのに84m秒って速すぎね?
84m秒のベンチマークを100回やるのがいいのか8.4秒のベンチマークを1回やるのがいいのかで遅いほうがいいと思うんだが
259(1): 2025/10/06(月)01:20 ID:bQ0ntySb(1/2) AAS
フィボナッチ数は行列累乗を理解してないから乗数の数だけ掛け算やってるし、素数の方は「エラトステネスのふるいを純朴に利用して」と書いてる割に剰余計算で余りがでたものを倍数としてフィルタする処理になってて全然エラトステネスのふるいじゃないなあ、ダメだこりゃ。
どちらの記事もアルゴリズムへの理解がなくて効率悪いことやってるんだが、こういう記事平気で公開してる人が
地球温暖化とコンピュータのエネルギー消費の問題にElixirで立ち向かう〜「コンピュータと地球温暖化は
決して無縁ではない」(2022年版)
外部ﾘﾝｸ:qiita.com
なんて記事書いてて頭が痛い。
これで大学の先生ってなあ、冗談なら良いのに。
260: 2025/10/06(月)01:25 ID:bQ0ntySb(2/2) AAS
>>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
261: 2025/10/06(月)06:36 ID:53QY0HCL(1) AAS
>>259
エラトステネスのふるいは、
作業メモリをその数だけ必要とすることと引き換えに、
足し算だけで素数を求めることができるアルゴリズムだから、
遅い剰余算を用いた時点で失格となりますね。
エラトステネスのふるいの場合をベンチマークとして比較しているわけでもないようてすね。
262: 2025/10/06(月)08:49 ID:0Xz/SJfu(1) AAS
この先生はElixirみたいなニッチな言語研究するより先にアルゴリズムの勉強したほうが良いと思う。
現状では学部の学生並みの知識もある気がしない。
263: 2025/10/09(木)14:36 ID:/RUFLlG7(1) AAS
『【C言語】char型の落とし穴~オーバーフロー~』
charの変数の値はintに昇格されてから加算されるのでこの場合オーバーフローしないし、intからcharに型変換する際にビットが捨てられるのもオーバーフローじゃないけど、この記事は何をオーバーフローと呼んでいるのか?
264: 2025/10/09(木)15:40 ID:KD7T9yPY(1) AAS
Cしか使えない特殊な環境ならともかく
勝手に異なる型へ自動変換されて困ったことになる弱い型付け言語のCを使ってる情弱の知識はそんなもんだ
265: 2025/10/10(金)00:22 ID:SqpOO1WH(1/2) AAS
外部ﾘﾝｸ:qiita.com
> ご指摘ありがとうございます。数値を修正しました...
コンパイルエラーが出るよう修正するとかｗ
外部ﾘﾝｸ:gcc.godbolt.org
266: 2025/10/10(金)01:56 ID:3qfmD/kK(1) AAS
今となっては未定義動作だらけの欠陥言語Cにこだわる人はほぼ異常者だな
残りは特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ
267(1): 2025/10/10(金)08:25 ID:ckTDD7bx(1/7) AAS
組み込みの世界知らない人かな
268(1): 2025/10/10(金)09:05 ID:FYVFXot6(1) AAS
C以外は特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人って事?
269: 2025/10/10(金)09:11 ID:9zFqUBbx(1) AAS
>>267
それはコレやね
>>特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ
270: 2025/10/10(金)09:17 ID:JrlTg/8e(1) AAS
>>268
C以外に未定義動作だらけなクソ言語あるの？
271: 2025/10/10(金)09:30 ID:ckTDD7bx(2/7) AAS
> C以外に未定義動作だらけなクソ言語あるの？
C++も聞いたことない人かあ
272: 2025/10/10(金)10:03 ID:Joie9IL1(1) AAS
C/C++は同罪だね
C++が失敗した理由はいくつも挙げられてきたけど
拡張方法の失敗に加えてCの未定義動作を埋めきれなかったことが響いてる
273(1): 2025/10/10(金)10:10 ID:EYYPWczZ(1) AAS
Javaでもメソッド無いの初期化されていない変数とかで失敗するけど
未定義動作になるのを言語のせいとか言ってるけど自分が必用な値が自動でセットされるわけじゃないのだからそういう奴ってバグを作り出す
274: 2025/10/10(金)10:23 ID:c258Qk98(1) AAS
>>273
Javaでは未定義動作にならないため問題は起きません
ローカル変数は初期化しないとエラー
インスタンス変数はデフォルト値で自動的に初期化されます
デフォルト値は各型により0やfalseやnullなど定まっています
Cの実行するたびに値が変わる問題はJavaでは起きません
275(4): 2025/10/10(金)12:28 ID:ckTDD7bx(3/7) AAS
最適化のなしかありかで挙動の変わる言語があるらしいけどそういうのは最悪。
fn main() {
let mut sum: i8 = 0;
let mut num: i8;
num = 100;
sum += num;
num = -10;
省7
276: 2025/10/10(金)12:45 ID:AslPjXj+(1) AAS
その辺見越して大きい値扱える変数使って明示的にうまいことやるからどうでもいいんだよなあ
277: 2025/10/10(金)12:56 ID:BIOy5Wv+(1) AAS
>>275
debug modeとrelease modeの違い
標準状態ではdebug modeで動作
実行時コストをかけて様々な検出をしてくれる
release modeでは明示的な実行時コスト指定ex. checked_add()などがある時のみ
278(1): 2025/10/10(金)17:34 ID:ckTDD7bx(4/7) AAS
x86やARMでオーバーフローチェックのコストなんて大したものではないので、最適化有効の場合でもオーバーフローチェックは行うのがフェイルセーフ的に正しいな。
オーバーフローチェックのコストが問題になるレアケースでは記述を変える対応が良い。
そういう判断できなかった辺りが残念言語なんだよなあ。
279(5): 2025/10/10(金)19:59 ID:EwscZStB(1/4) AAS
>>278
オーバーフローチェックのコストはとんでもなく高いんだよ。
演算命令1つ行なう毎に、そこで立った条件フラグによる条件分岐を毎回行なう必要がある。
これはコンパイラが行なうコードの並べ替えやループの展開やベクトル化などを全て阻止してしまう。
劇的に遅くなることが判っているよ。
さらにアセンブリ言語を書いたりコンパイル結果を見たりしたことがあれば理解しやすいけど、
条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。
そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。
常にオーバーフローフラグを必要とするならそれもできなくなってしまう。
条件フラグをレジスタやメモリに一時退避させるコストもかかってくるんだよ。
280(1): 2025/10/10(金)21:05 ID:ckTDD7bx(5/7) AAS
いまどきのプロセッサは分岐予測も優秀だし分岐しない条件分岐命令は大してペナルティならねぇよアホか。
281(1): 2025/10/10(金)21:12 ID:ckTDD7bx(6/7) AAS
＞条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。
＞そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。
知らないこと想像で書いてて大変宜しいｗ
282: 2025/10/10(金)21:29 ID:EwscZStB(2/4) AAS
>>280
理解できていないようだけど、
演算命令の順序が固定かつシリアル化されてしまうことが大きいんだよ。
命令順序の入れ替えは最適化の基幹であるとともに、並列展開もできなくなってしまう。
さらに条件フラグの保存コスト問題も生じてしまう。
283(1): 2025/10/10(金)21:32 ID:EwscZStB(3/4) AAS
>>281
x86など使ったことある人には常識だけど、
条件フラグの更新を伴う加算と伴わない加算としてADD命令とLEA命令の使い分けをコンパイラも多用しているよ。
それ以前の演算で反映された条件フラグを変化させないまま、
LEA命令によって加算や一部の乗算及びその組み合わせ演算をできる利点があるためだよ。
284(1): 2025/10/10(金)23:12 ID:ckTDD7bx(7/7) AAS
実例挙げられない辺りが限界なんだろうなあｗ
285: 2025/10/10(金)23:19 ID:EwscZStB(4/4) AAS
>>284
実例を既に>>283で挙げたよ。
もしかしてアセンブラ使ったことすらなくて理解すらできなかった？
286: 2025/10/10(金)23:42 ID:SqpOO1WH(2/2) AAS
どのコンパイラがどういうコード吐いてるかも示せないで実例とか言ってるのはたまげたなｗ
287: 2025/10/11(土)00:12 ID:e8fGXa5a(1) AAS
ADDではなくLEAでフラグ変化させずに加算演算するのは手動でもコンパイラでも基本
この常識を理解できない低レベルな人はコード書いたりコンパイラ生成コードを見たことすらない人
288: 2025/10/11(土)10:05 ID:mX/iHQDj(1/2) AAS
コンパイラが出力した「条件フラグを変更せず保持したまま演算を行なう」コードの実例から逃げてるとこ見ると「LEAで加算ができる」が知識の限界の人かな
289: 2025/10/11(土)10:12 ID:mX/iHQDj(2/2) AAS
> コンパイラ生成コードを見たことすらない人
このスレでCompiler Explorerのアドレス貼ってる人は珍しくないので（>>150とか）同様にして見せてやれば良い。
290(1): 2025/10/12(日)03:13 ID:obnnOjq+(1) AAS
Rust信者ってこんなもんだなあとういうのはまあ納得
291: 2025/10/12(日)03:35 ID:Iv4aWOmO(1) AAS
Rust？
関係ないだろ
292: 2025/10/12(日)05:25 ID:D80drn0C(1) AAS
マシン語にするプログラミング言語は最適化によって意図と違うコードになることがあるという話をしたいんだろ。
293: 2025/10/12(日)12:59 ID:EE9svh1n(1/2) AAS
> Rust？
> 関係ないだろ
>>275からの話の流れが理解できない人かな
294: 2025/10/12(日)19:07 ID:txsY3oX4(1/2) AAS
>>275
このRustプログラムが最適化あり（リリースビルド）／最適化なし（デバッグビルド）で挙動が変わる理由は、i8型の符号付き整数オーバーフローの扱い方が状況によって異なるためです
最適化なし（デバッグビルド）
sum += numで加算の結果がi8の範囲（-128～127）を超えてしまうと、panicになるため意図した出力が得られず、エラーが発生します
最適化あり（リリースビルド）
オーバーフローのチェックが省略されて二の補数によるラップアラウンド（桁あふれの結果として範囲内に収める計算）が行われます
295: 2025/10/12(日)19:15 ID:txsY3oX4(2/2) AAS
リリースビルド（最適化あり）でもオーバーフローを検出し、デバッグビルド（最適化なし）と同じ挙動にする方法があります
Cargo.tomlに以下を追記します：
[profile.release]
overflow-checks = true
リリースビルドでも整数オーバーフローが発生するとpanic（異常終了）になります
296: 2025/10/12(日)20:41 ID:VrekPvIE(1/2) AAS
デフォで安全側に倒してない時点で残念言語だな
297: 2025/10/12(日)21:03 ID:UHx3WDzt(1/2) AAS
オーバーフローでプログラムを中断したいのか
オーバーフローをエラーとして返したいのか
オーバーフローを値として受けて活用したいのか
オーバーフローは影響しない処理なのか
一般的に様々な状況が考えられる
これは安全性の問題とは関係がない
298(1): 2025/10/12(日)21:59 ID:VrekPvIE(2/2) AAS
> オーバーフローでプログラムを中断したいのか
> オーバーフローをエラーとして返したいのか
> オーバーフローを値として受けて活用したいのか
> オーバーフローは影響しない処理なのか
> 一般的に様々な状況が考えられる
話についてこれない人かな
299: 2025/10/12(日)22:06 ID:UHx3WDzt(2/2) AAS
>>298
オーバーフローをどう処理したいかはプログラミングの内容に依って変わる
これは安全性の問題ではない
300: 2025/10/12(日)22:47 ID:EE9svh1n(2/2) AAS
オーバーフローを無視して処理を続けていいわけはないので安全性の話なんだよなあ
何言ってんのこの人ｗ
301: 2025/10/12(日)22:55 ID:jaSkqZ+M(1) AAS
オーバーフローは無視できる処理もあるし、オーバーフローが起きない場合もあるわけだから、そこはケースバイケースやろ。
状況次第としか。
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だと「普通の関数内の配列」にはスタックに置かれるものもあるんですが
要素数はコンパイル時に決まってる必要はあるけど
322: 2025/10/14(火)21:04 ID:ZulSE3F6(1) AAS
>>321
違いは簡単
静的メモリ配置 ←アドレス固定
動的メモリ配置 ←アドレス変動
static宣言すると静的にメモリ領域が確保されてアドレスが固定になる
実例コード
void foo() {
static int a1[] = {1, 2, 3};
int a2[] = {1, 2, 3};
printf("アドレス固定 a1: %p\n", &a1);
省10
323: 2025/10/15(水)01:32 ID:F/Bk7x58(1) AAS
>>316
>>321
staticの意味は「静的な」
staticを付けないと動的に毎回確保されることくらい分かりそうなものだが
324(1): 2025/10/15(水)02:42 ID:tBMKGpTr(1) AAS
なんてことだstatic宣言した変数が共有ライブラリの中だとアドレスが変わることがあるゾ！
325: 2025/10/15(水)02:49 ID:LnEbzNuN(1) AAS
>>324
リンク時に変わることはあっても
実行中にアドレスが変わることはない
326: 2025/10/15(水)18:27 ID:V1g0382z(1) AAS
cの静的動的はサイズが実行時に定まるか否かってことじゃないん？
staticかどうかはcプログラマにとっては別の感心事で
メモリの動静を語るときはそうだったと思うけど
俺の知ってる限り
staticつけてないローカルな配列のことを動的な確保って言ってる人見たこと無いわ
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が異端だったな
そこまでの行き過ぎた過剰を他の言語は求めていないのだと思われる
347: 2025/10/18(土)23:17 ID:63qoaJUs(1/2) AAS
最適化指示でオーバーフロー検出が働くなるRustの仕様が適当かはRustの開発コミュでもたびたび議論になってることなのに「現行がこうなってる」で納得してるのは思考停止なんだよなあ。
348(1): 2025/10/18(土)23:33 ID:3aakVM9g(1) AAS
Rustはプロジェクトを作る時にオーバーフローのチェックを強制したい方針ならばこの指定機能が何年も前に入ったため今は大丈夫だよ
overflow-checks = true
349: 2025/10/18(土)23:42 ID:63qoaJUs(2/2) AAS
>>348
そういうの気にしない馬鹿のためにデフォルトの挙動はどうであるべきかって話が理解できない奴は安全性について語らない方が良いよ。
350: 2025/10/18(土)23:49 ID:7LIpXt77(1) AAS
RustがIT各社に次々と採用されていってる理由は企業から見ても安全性が最も良い言語であると支持されたため
351: 2025/10/19(日)20:21 ID:+RR12fUB(1) AAS
『🏆最小自由数で競う！C++, Lisp, Rust, Mojoによる速度対決🔥 / Competing on the Minimum Free Number! Speed Battle with C++, Lisp, Rust, and Mojo 🔥』
外部ﾘﾝｸ:qiita.com
「そのコードは良くない。こう書くべき」みたいな具体的なコメントができない辺りがRust信者の限界なのかな
352: 2025/10/20(月)22:42 ID:RnZTjdTH(1) AAS
このスレ見る限りRust信者はコード書けないみたいだしなあ
上下前次1-新書関写板覧索設栞歴
あと 416 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s