Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次1-新
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信者はコード書けないみたいだしなあ
353: 2025/10/21(火)15:24 ID:2uplBhQe(1/4) AAS
> オーバーフローチェックのコストはとんでもなく高いんだよ。
> 劇的に遅くなることが判っているよ。
安全性よりパフォーマンスが重要と思ってる人は根本的なところから分かってない。
354: 2025/10/21(火)16:11 ID:PAfcSIKV(1) AAS
安全重視のJavaもオーバーフローチェックしないよ
355: 2025/10/21(火)16:42 ID:bG0rJrvl(1) AAS
もはや誰もQiitaの話をしていないのである
356: 2025/10/21(火)17:18 ID:2uplBhQe(2/4) AAS
30年前の設計のJavaを安全重視と信じてる人がいるとはたまげたなあ
357: 2025/10/21(火)17:46 ID:d/sWvnzZ(1) AAS
最近の言語Go Nim RustなどもCやJavaと同様にデフォルトではオーバーフロー時にラップアラウンド
358: 2025/10/21(火)18:39 ID:2uplBhQe(3/4) AAS
> 最近の言語Go Nim RustなどもCやJavaと同様にデフォルトではオーバーフロー時にラップアラウンド
C言語では符号付き整数のオーバーフローは未定義動作なんだがそんなことも知らない輩がなんか言ってなんだなあ。
359: 2025/10/21(火)19:12 ID:CCxWu0hF(1) AAS
デフォルトでオーバーフローチェックしなくて問題になった話を聞いたことがないな
世の中のシステムは問題なく動いているもんな
チェックしたければオーバーフローチェックできるから何が問題なのかわからん
360: 2025/10/21(火)19:36 ID:2uplBhQe(4/4) AAS
255からエクステンドでゲームオーバーなんてザラにあるのにな
361: 2025/10/21(火)23:13 ID:Xc9g4ZCw(1/2) AAS
>>43
『VRでもリアル空間でもスマホでも！「sonoXR」での音楽体験を実現する先端技術・FPGA独自チップ』
外部ﾘﾝｸ:note.com
↑の記事で当日の様子が紹介されてる。
> そのElixirChipですが、2025年9月17日、Elixir関連コミュニティのオンラインLT会で初お披露目されました！
> LT会のデモンストレーションでは、macの画面共有でElixirChipがターミナルから実行されている処理が映し出されて、その解説がメインのお話だったのですよね。
> それもそのはず。
> FPGA（Field Programmable Gate Array）とは「内部の論理回路をソフトウェアのように後から自由に組み替えられるチップ」のことだというのを、このLT会で今更ながら理解しました。（お恥ずかしい・・・）
> 私はElixirChipの開発を行う株式会社Digidock Consultingにてセールスエグゼクティブも担当しています。
省1
362: 2025/10/21(火)23:25 ID:Kzm3UPI2(1) AAS
64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
363: 2025/10/21(火)23:37 ID:Xc9g4ZCw(2/2) AAS
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
2**64/(365.25*24*3600*10000000000) = 58.4542046091 だから59年目でオーバーフローするだろ。
364: 2025/10/22(水)00:52 ID:36Oigqe9(1) AAS
8bit時代は一瞬で溢れたのに
64bit時代は凄いな
365: 2025/10/22(水)02:05 ID:1Zu7PCWv(1) AAS
５９年に1回だけ出現するバグがすごい
毎年再起動で対応すべき
366: 2025/10/22(水)02:24 ID:W6apSoTE(1) AAS
最新のCPUでも10GHz行かないので1秒間に100億回のカウントが無理だよな
オーバーフローするまでもっとかかる
367: 2025/10/22(水)02:29 ID:kkMCRZ3c(1) AAS
フィボナッチはオーバーフローする
368: 2025/10/22(水)02:49 ID:DMZH9rqW(1) AAS
オーバーフローチェック関数を呼び出せばいい
369: 2025/10/22(水)07:42 ID:pPjVNDwq(1/3) AAS
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
こういうマヌケが今後もいなくなることはないからオーバーフローチェックは常に行うのが安全。
370: 2025/10/22(水)08:11 ID:UieYLCLo(1) AAS
溢れないんだからチェックは無駄じゃん
だから昔からチェックしない言語が使われてるんだろ
文句があるならここで暴れずに各言語に公式に言えばいい
371: 2025/10/22(水)09:13 ID:hPyx8jr0(1/3) AAS
Rustは多段階に対応しているよ
デフォルトはデバックモードになりオーバーフロー含めた様々なチェックが充実
プロジェクト毎に常にオーバーフローチェックをする指定が可能
オーバーフローを扱う関数も多数あり
372: 2025/10/22(水)09:20 ID:pPjVNDwq(2/3) AAS
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
こういうマヌケはプロジェクトにオーバーフローチェックを行う指定なんてしないしオーバーフローを扱う関数を呼ぶこともないんだよなあ。
373: 2025/10/22(水)09:30 ID:hPyx8jr0(2/3) AAS
安全性の対策ができるかどうかが重視されている
安全性の対策のためにRustは次々と採用されている
対抗できるプログラミング言語が他にないからね
374: 2025/10/22(水)09:37 ID:pPjVNDwq(3/3) AAS
Rustを使えば安全という勘違い
375: 2025/10/22(水)09:41 ID:hPyx8jr0(3/3) AAS
Rustに勝てるプログラミング言語がないんだよ
だからこそIT大手がこぞってRustを採用した
376: 2025/10/22(水)16:35 ID:h019lk2V(1/2) AAS
○bitまで演算できるから大丈夫
だったのが、整数型をオーバーする●年問題とか起きたんだよ
そして今度は◯bitまで使えるから安心と結局は同じ事を繰り返してるだけ
なのに「ずっと使い続けても大丈夫」とか言えるものなんだな
377: 2025/10/22(水)16:36 ID:h019lk2V(2/2) AAS
それプログラム言語で勝ちとか
何が言いたいのだか
378(1): 2025/10/22(水)18:57 ID:Hv/mNdUH(1/5) AAS
>>279
> オーバーフローチェックのコストはとんでもなく高いんだよ。
> 劇的に遅くなることが判っているよ。
このスレのRust信者はコードが書けない馬鹿しかいないのでオーバーフローチェックのコストとやらがとんでもなく高いことの例示すらできないんだよなあ。俺が代わりに確認してやったぞ。
最適化レベル3 オーバーフローチェックなし(-Copt-level=3)
外部ﾘﾝｸ:wandbox.org
最適化レベル3 オーバーフローチェックあり(-Copt-level=3 -Coverflow-checks=yes)
外部ﾘﾝｸ:wandbox.org
379(2): 2025/10/22(水)20:39 ID:TnWf0U/l(1) AAS
>>378
コードを書けないのはおまえだろ
その出力結果を見ろよ
999999999 0.000000 sec.
380: 2025/10/22(水)21:14 ID:Hv/mNdUH(2/5) AAS
> コードを書けないのはおまえだろ
> その出力結果を見ろよ
何が起こってるか分からんとこういう反応ｗ
381(1): 2025/10/22(水)21:44 ID:5MvhTmyF(1) AAS
実行時間0秒ということはコンパイル時の定数化だろうね
コードを正しく書けない人が定数データをそのまま使って正しくベンチマーク計測できていない典型的な失敗例
382: 2025/10/22(水)22:01 ID:Hv/mNdUH(3/5) AAS
>>379
>>381
「とんでもなく高い」と>>279が言ってるオーバーフローチェックをコンパイル時にやれてることが理解できない低能ｗ
383: 2025/10/22(水)22:11 ID:wCiIvwD8(1) AAS
比較ベンチを測るプログラムでコンパイル時に定数になってしまってるのは初心者あるあるでちよっと恥ずかしい
さらに定数になったことでオーバーフローチェックは軽いと主張している人は恥ずかしいを通り越してキチガイ
384: 2025/10/22(水)22:25 ID:Hv/mNdUH(4/5) AAS
> さらに定数になったことでオーバーフローチェックは軽いと主張している人は恥ずかしいを通り越してキチガイ
コスト0でできるオーバーフローチェックの例を挙げただけだけど馬鹿だとこういう理解になんのなｗ
385: 2025/10/22(水)22:40 ID:aaZcXuwG(1) AAS
連投クンは3つの過ちを犯している
①実行時間の比較をすべきところでコンパイル時に定数となるコードを書いてしまった
②その結果をもってコスト0だと主張
③その事例をもってオーバーフローチェックは重くないと主張
386: 2025/10/22(水)22:53 ID:Hv/mNdUH(5/5) AAS
> ?実行時間の比較をすべきところでコンパイル時に定数となるコードを書いてしまった
オーバーフローチェックのコストの話だからコンパイル時にできるんなら御の字なんだよなあ。
> ?その結果をもってコスト0だと主張
俺が挙げた例ではその通り。
> ?その事例をもってオーバーフローチェックは重くないと主張
省2
387: 2025/10/22(水)23:22 ID:MJsEo9z/(1) AAS
定数の同士の計算をコンパイル時にできるだけでしょ
普通は定数同士ではないためオーバーフローのチェックをコンパイル時にできるわけではないよ
388: 2025/10/23(木)00:01 ID:F7QtUS8E(1/3) AAS
> 定数の同士の計算をコンパイル時にできるだけでしょ
同じコードで「最適化レベル3 オーバーフローチェックなし」では定数の同士の計算をコンパイル時にできていないので場合による。rustcは最適化が控えめなのでオーバーフローチェックを行ったほうがデータフロー解析を深いレベルで行なって効率良いコードを吐いてくれる可能性まである。
> 普通は定数同士ではないためオーバーフローのチェックをコンパイル時にできるわけではないよ
できる場合もあればできない場合もある。
安全性を蔑ろにして良いわけはないのでコンパイル時にできないのであれば実行時のオーバーフローチェックは行うべき。そのコストが問題になるのであればプログラマがオーバーフローしないことを保証してやれば良い。
389: 2025/10/23(木)00:05 ID:OBXMa/ZD(1) AAS
言い訳ばかりだな
オーバーヘッドを比較するための実行時間ベンチマークで
まともなプログラマーならばコンパイル時定数になるコードを書かない
390: 2025/10/23(木)00:08 ID:F7QtUS8E(2/3) AAS
コンパイル時にオーバーフローチェックされた例が余程悔しかったと見えるｗ
391: 2025/10/23(木)00:10 ID:F7QtUS8E(3/3) AAS
つか何で
> オーバーフローチェックのコストはとんでもなく高いんだよ。
という具体的を提示しないんだろうか?
392: 2025/10/23(木)01:00 ID:eRkhgGUb(1) AAS
>>379
実行時間を比較しようとして定数計算で実行時間0.000秒は草
それをそのまま貼るのは慌てん坊
393: 2025/10/23(木)22:48 ID:qJPQXYyn(1) AAS
最適化レベル3 オーバーフローチェックなし
外部ﾘﾝｸ:wandbox.org
> 999999999 0.000000 sec.
最適化レベル3 オーバーフローチェックなし
外部ﾘﾝｸ:wandbox.org
> 999999999 0.192019 sec.
なるほど、確かに最適化控えめだなｗ
394: 2025/10/24(金)10:56 ID:1/8UQp8U(1/2) AAS
> オーバーフローチェックのコストはとんでもなく高いんだよ。
clangより遅いRustがますます遅くなっちゃうってことか。
でもそれで安全性と天秤に掛けて安全性捨てて良いって理屈にはならんと思うが。
395(1): 2025/10/24(金)11:39 ID:pf7VrHln(1) AAS
Rustはオーバーフローに関しても最も充実している言語
まずデフォルトではデバッグモードとなりオーバーフローを含めた様々な問題をチェックして指摘してくれる
次にオーバーフローを取り扱う関数が30個以上と充実しておりオーバーフロー時に様々な対処ができるようになっている
さらにオーバーフローチェック強制モードを指定することもできる
396: 2025/10/24(金)12:33 ID:1/8UQp8U(2/2) AAS
肝心のユーザーが
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
こんなこと言ってるようじゃせっかくの機能も台無し。
こういうユーザーはオーバーフローを軽視しているので、それを扱う関数を呼んだりオーバーフローチェック強制モードを指定することもしない。
397: 2025/10/24(金)12:54 ID:yjIuofsm(1) AAS
Rustより優れているプログラミング言語がなく出現しそうにない
IT大手をはじめとして各社が次々とRust採用に踏み切った理由
398: 2025/10/24(金)21:32 ID:Rjl1Yp+F(1) AAS
何をもって優れてるというのか知らんけど
採用される率だったら圧倒的に Python や JavaScript じゃないの？
399: 2025/10/24(金)22:24 ID:sOhxBEuL(1) AAS
普及している言語を採用するのは当たり前
普及してない言語をわざわざ採用するのは他の言語では代わりにならないほどメリットがある時
400: 2025/10/24(金)23:11 ID:dp05dd3l(1) AAS
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
この程度の実行時検出もできなくて「メリットがある」と言い張ってて草ｗ
401: 2025/10/25(土)00:27 ID:dZEZZMvJ(1) AAS
見ていてなんとなくわかってきた
プログラミング言語として敵わないからよくわからない言いがかりをつけてずっと粘着しているだけのような
402(1): 2025/10/25(土)08:20 ID:7tgM5Cd8(1) AAS
言語の優劣（笑）にこだわってる子が一人だけおるっていう状況かな
自己のアイデンティティを借り物で満たそうとしちゃってるね
自分がRustの作者ってんならともかく、単なるユーザでしかないのにね
403: 2025/10/25(土)08:45 ID:0A7PnaiQ(1) AAS
>>395
オーバーフローに関してそこまで充実していない言語も多いけど、なぜか充実している言語の方をしつこく叩いてるコンプレックス持ちがおるから面白い。
404: 2025/10/25(土)11:38 ID:APUPz67M(1/5) AAS
安全性分かってない奴がRust盲信してて笑われてるだけｗ
405(1): 2025/10/25(土)11:52 ID:HsDC01zZ(1) AAS
>>52
> Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
> 安全性などはついでのオマケ
IDコロコロ君安全性は屁のように考えてるみたいだけど、だったら配列アクセスのたびに範囲チェックで無駄なコスト払ってるRustは良い言語ではないんじゃね? それかunsafeでポインタアクセスするのが正義?
406: 2025/10/25(土)11:53 ID:H3w3YKY0(1) AAS
安全性のためにRustを採用するところが世界的にどんどん増えているのはなぜだろう？
407: 2025/10/25(土)11:59 ID:APUPz67M(2/5) AAS
Rustの普及と
> 安全性などはついでのオマケ
とか言っちゃう馬鹿が笑われてるのは別の話だゾｗ
408(1): 2025/10/25(土)12:07 ID:LnBfHi83(1) AAS
>>405
Rustは配列などのアクセスもゼロコスト抽象化で速さと安全性を両立してるよん
409: 2025/10/25(土)12:58 ID:APUPz67M(3/5) AAS
>>408はrustcの出力見たことない人かな?
配列の範囲チェックって
外部ﾘﾝｸ:godbolt.org
> cmpq %rsi, %rdx
> jae .LBB0_7
↑がそれ。
ちなみにCだとこんなだ。
外部ﾘﾝｸ:godbolt.org
410: 2025/10/25(土)13:03 ID:APUPz67M(4/5) AAS
rustcが最適化控えめという話は既出か。
rustc
外部ﾘﾝｸ:godbolt.org
clang
外部ﾘﾝｸ:godbolt.org
411(1): 2025/10/25(土)17:01 ID:L+Kq+g5v(1) AAS
C言語は、ポインタが、ヤバイくて、危ないよね。
RUST言語は、ポインタが、無いのなら、安全ぢゃねえ?
412: 2025/10/25(土)17:40 ID:zF/r+ywr(1/2) AAS
>>402
マジでこれ
関数型言語あたりに多いけど、自分が好きな言語をアイデンティティにしてる奴にまともなのはいない
自分は何を作れるか・何を作ったかの方がプログラマにとっての価値だろ
413: 2025/10/25(土)18:04 ID:zF/r+ywr(2/2) AAS
個人開発ならともかく、仕事で使う言語は自分の好みじゃなくて組織によって決まるものだよね
Rustが好きでも、Goのプロジェクトに入ったらGoを書く、Javaのプロジェクトに入ったらJavaを書くのがプロ
宣言的なコードが好きだからといって、OOPの言語や、for文 と if文 をひたすら書かされる言語では仕事したくないです、なんてのは社会人としてだめでしょ
(Rustを使える企業に転職する、という選択ができる人は別だけど)
414: 2025/10/25(土)19:23 ID:KXTmWn4e(1) AAS
企業や立場によってピンキリだよ
そういう歯車として使われる人もいればそうでない人もいる
415: 2025/10/25(土)19:50 ID:SFAxzZT/(1) AAS
どの分野でもAとBの比較の話をしている時に同じことが起きてるな
純粋にそれぞれの特徴やメリットで優劣を比較すればいい
ところが不利になった側はどの話でもこう言い出す
Aを使うやつはXXXだ！Aの価値よりおまえの価値はどうなんだ！
AとBの比較から逃避して人間の攻撃を始める
上下前次1-新書関写板覧索設栞歴
あと 353 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s