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

**デフォルトの名無しさん** · 2025/09/13(土) 12:24:07.83

Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)

https://qiita.com/

Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。

https://internet.watch.impress.co.jp/docs/news/1025972.html

前スレ Qiita
https://mevius.5ch.net/test/read.cgi/tech/1542357242/
Qiita 2 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1658762410/
Qiita 3 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1685235361/
Qiita 4 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1705486836/
Qiita 5 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1717651046/
Qiita 6 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1739527246/

**デフォルトの名無しさん** · 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;
}

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

>>316
>>321
staticの意味は「静的な」
staticを付けないと動的に毎回確保されることくらい分かりそうなものだが

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

なんてことだstatic宣言した変数が共有ライブラリの中だとアドレスが変わることがあるゾ！

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

>>324
リンク時に変わることはあっても
実行中にアドレスが変わることはない

**デフォルトの名無しさん** · 2025/10/15(水) 18:27:52.24

cの静的動的はサイズが実行時に定まるか否かってことじゃないん？
staticかどうかはcプログラマにとっては別の感心事で
メモリの動静を語るときはそうだったと思うけど
俺の知ってる限り
staticつけてないローカルな配列のことを動的な確保って言ってる人見たこと無いわ

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

Grokに訊いたら非標準のallocaやC99のVLAは動的確保に含まれる場合があるそうだ。

**デフォルトの名無しさん** · 2025/10/15(水) 19:43:01.58

配列やベクタやリストやスライスなど、言語によって様々な呼び方や実装が異なるもの、全てに共通の必須な仕組みとして、
総称としての配列の範囲チェックの話をしていて、そのまま特定の言語に関係なくこの話の流れでいいんだよな

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

静的と動的は様々な対象に用いられるが、今回は静的メモリ確保
これをアドレスが変わらないという解釈でも、いわゆるセグメントのうち静的領域に確保するという意味でも同じ
特定の言語の話ではないが、例えばC言語なら静的宣言(static宣言)をする変数がこれに該当する

動的メモリ領域は毎回アドレスが変わるという意味でも、何かをするたびにメモリ空間から領域を確保する意味でも同じ
ただし二つに分かれて、関数呼び出しのたびに領域が確保されて関数から去ると無効になるものと、関数呼び出しのタイミングと関係なく確保することで関数を去っても有効になるもの、それら二つの異なる性質のものに分かれる
いわゆるセグメント領域としては、前者はスタック領域に確保されて後者はヒープ領域に確保される
前述の静的領域の変数とは異なり、スタック領域やヒープ領域に動的に確保することが共通の特徴であり、タイミングによってアドレスも変化する

**デフォルトの名無しさん** · 2025/10/15(水) 22:57:25.39

>>317
コレクションという言葉を知らないのか？
配列は連続したメモリ領域だぞ？

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

>>320
あのさ、関数でも関数を呼び出す方でも実行時にメモリを確保するんだよ？

実行中にメモリを確保することは、また別の話。

**デフォルトの名無しさん** · 2025/10/15(水) 23:03:30.96

>>328
CPUとOSレベルで別のプロセスが使っているメモリ領域にアクセスできないようになっていることを知らない高齢者か？

進化を知らずに大昔の仕様で語るのはやめろ。

**デフォルトの名無しさん** · 2025/10/15(水) 23:14:46.54

連投が全て的外れでワロタ

>>329
元レスはコレクションとも連続領域とも全く無関係な話だな

>>330
区別ついてないのかよ
静的な変数が置かれる静的領域は関数呼び出しと無関係に最初から存在するため遅くとも実行開始時点でアドレスが確定する

>>331
元レスに別プロセスの話もアクセス権もどこにも書かれてなく無関係
そもそもプロセス間の共有メモリがある

**デフォルトの名無しさん** · 2025/10/15(水) 23:26:49.61

>>332
元はメモリのアドレスをなめる行為の話だぞ？

飛び飛びのメモリ領域のことを一般的には配列とは呼ばない。コレクションの実装は飛び飛びのこともある。

**デフォルトの名無しさん** · 2025/10/15(水) 23:27:17.68

このスレはキータだったなw
変なやつしかいない

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

>>333
コレクションの話なんかどこにも出てきていないのに妄想で幻で見えてるのか？

**デフォルトの名無しさん** · 2025/10/15(水) 23:46:08.93

>>333
飛び飛びのメモリ領域の話をしてる人はいないと思いますよ
どうして突然そんなことを言い出すのですか？

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

『浮動小数点数に非常に小さい値を加えるとどうなるか？float型の精度限界を調べた』
　
知識がないところでFLT_EPSILONに近い概念を独自に発見しようとしてるのは偉いのだが、deltafの初期値を0.1fで始めてるのが惜しい。1.0fにしてればFLT_EPSILONの1/2が求まる筈。

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

>>279
> オーバーフローチェックのコストはとんでもなく高いんだよ。
> 劇的に遅くなることが判っているよ。

簡単なコードで確認してみた。
https://wandbox.org/permlink/L8hZILgJIhDYqDkB

**デフォルトの名無しさん** · 2025/10/18(土) 13:32:11.38

>>338 は32bitと大き目で更にoverflowしたらループを抜けるだけで代わりの値を代入したりしてない

unsigned charの8bit演算でoverflowしたら255にして
何回か毎に大きな値を引く(underflowは0)にする処理もあわせると分岐予測がある程度阻害されるのでは
(>>279 の具体的根拠は知らないけど)

**デフォルトの名無しさん** · 2025/10/18(土) 13:44:09.89

＞32bitと大き目で更にoverflowしたらループを抜けるだけで代わりの値を代入したりしてない
　
1から4を1億回足してるだけだからオーバーフローは発生しない。>>279が問題にしてるのはオーバーフローチェックのコストでありオーバーフローするかどうかは関係がない。

**デフォルトの名無しさん** · 2025/10/18(土) 19:06:57.05

実際のプログラムには足し算など無数にあるから分岐が無数に増えて分岐予測テーブルが溢れそう

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

Qiitaの話を全くしてないのは草

**デフォルトの名無しさん** · 2025/10/18(土) 20:38:26.02

現実的には関数呼出になるから遅い…が、使いどころなんてたかが知れてるよな

**デフォルトの名無しさん** · 2025/10/18(土) 20:49:39.50

結局こういうことだろね
現実と対応

303 デフォルトの名無しさん sage 2025/10/13(月) 02:39:47.42 ID:5mcGe2/B
オーバーフローのチェックのコストの重さ問題は特定の言語に関係なく全ての言語で生じる話だよ
そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ
そして必要に応じてオーバーフローのチェックをする関数を呼び出すなどして対応するよ

**デフォルトの名無しさん** · 2025/10/18(土) 22:24:24.75

> そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ

危険を承知で`-Ounchecked`を指定しない限りオーバーフローチェックを行うSwiftが安全性については唯一まともな判断してるってことだよなあ。
https://godbolt.org/z/fMc6KdPb1

**デフォルトの名無しさん** · 2025/10/18(土) 22:43:53.65

半開区間を長い左右非対称な記号で表わす話もSwiftが異端だったな
そこまでの行き過ぎた過剰を他の言語は求めていないのだと思われる

**デフォルトの名無しさん** · 2025/10/18(土) 23:17:36.52

最適化指示でオーバーフロー検出が働くなるRustの仕様が適当かはRustの開発コミュでもたびたび議論になってることなのに「現行がこうなってる」で納得してるのは思考停止なんだよなあ。

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

Rustはプロジェクトを作る時にオーバーフローのチェックを強制したい方針ならばこの指定機能が何年も前に入ったため今は大丈夫だよ
overflow-checks = true

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

>>348
そういうの気にしない馬鹿のためにデフォルトの挙動はどうであるべきかって話が理解できない奴は安全性について語らない方が良いよ。

**デフォルトの名無しさん** · 2025/10/18(土) 23:49:49.42

RustがIT各社に次々と採用されていってる理由は企業から見ても安全性が最も良い言語であると支持されたため

**デフォルトの名無しさん** · 2025/10/19(日) 20:21:17.40

『🏆最小自由数で競う！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信者の限界なのかな

**デフォルトの名無しさん** · 2025/10/20(月) 22:42:27.76

このスレ見る限りRust信者はコード書けないみたいだしなあ

**デフォルトの名無しさん** · 2025/10/21(火) 15:24:12.70

> オーバーフローチェックのコストはとんでもなく高いんだよ。
　
> 劇的に遅くなることが判っているよ。
　
安全性よりパフォーマンスが重要と思ってる人は根本的なところから分かってない。

**デフォルトの名無しさん** · 2025/10/21(火) 16:11:44.43

安全重視のJavaもオーバーフローチェックしないよ

**デフォルトの名無しさん** · 2025/10/21(火) 16:42:19.08

もはや誰もQiitaの話をしていないのである

**デフォルトの名無しさん** · 2025/10/21(火) 17:18:52.11

30年前の設計のJavaを安全重視と信じてる人がいるとはたまげたなあ

**デフォルトの名無しさん** · 2025/10/21(火) 17:46:00.64

最近の言語Go Nim RustなどもCやJavaと同様にデフォルトではオーバーフロー時にラップアラウンド

**デフォルトの名無しさん** · 2025/10/21(火) 18:39:21.79

> 最近の言語Go Nim RustなどもCやJavaと同様にデフォルトではオーバーフロー時にラップアラウンド
　
C言語では符号付き整数のオーバーフローは未定義動作なんだがそんなことも知らない輩がなんか言ってなんだなあ。

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

デフォルトでオーバーフローチェックしなくて問題になった話を聞いたことがないな
世の中のシステムは問題なく動いているもんな
チェックしたければオーバーフローチェックできるから何が問題なのかわからん

**デフォルトの名無しさん** · 2025/10/21(火) 19:36:04.80

255からエクステンドでゲームオーバーなんてザラにあるのにな

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

>>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独自チップ」とか言ってんのスゲエな。

**デフォルトの名無しさん** · 2025/10/21(火) 23:25:43.96

64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない

**デフォルトの名無しさん** · 2025/10/21(火) 23:37:30.32

> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない

2**64/(365.25*24*3600*10000000000) = 58.4542046091 だから59年目でオーバーフローするだろ。

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

8bit時代は一瞬で溢れたのに
64bit時代は凄いな

**デフォルトの名無しさん** · 2025/10/22(水) 02:05:57.52

５９年に1回だけ出現するバグがすごい
毎年再起動で対応すべき

**デフォルトの名無しさん** · 2025/10/22(水) 02:24:22.73

最新のCPUでも10GHz行かないので1秒間に100億回のカウントが無理だよな
オーバーフローするまでもっとかかる

**デフォルトの名無しさん** · 2025/10/22(水) 02:29:12.26

フィボナッチはオーバーフローする

**デフォルトの名無しさん** · 2025/10/22(水) 02:49:06.07

オーバーフローチェック関数を呼び出せばいい

**デフォルトの名無しさん** · 2025/10/22(水) 07:42:15.54

> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
　
こういうマヌケが今後もいなくなることはないからオーバーフローチェックは常に行うのが安全。

**デフォルトの名無しさん** · 2025/10/22(水) 08:11:36.58

溢れないんだからチェックは無駄じゃん
だから昔からチェックしない言語が使われてるんだろ
文句があるならここで暴れずに各言語に公式に言えばいい

**デフォルトの名無しさん** · 2025/10/22(水) 09:13:09.53

Rustは多段階に対応しているよ
デフォルトはデバックモードになりオーバーフロー含めた様々なチェックが充実
プロジェクト毎に常にオーバーフローチェックをする指定が可能
オーバーフローを扱う関数も多数あり

**デフォルトの名無しさん** · 2025/10/22(水) 09:20:59.95

> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
　
こういうマヌケはプロジェクトにオーバーフローチェックを行う指定なんてしないしオーバーフローを扱う関数を呼ぶこともないんだよなあ。

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

安全性の対策ができるかどうかが重視されている
安全性の対策のためにRustは次々と採用されている
対抗できるプログラミング言語が他にないからね