Qiita 7 - キータぞ、来たぞ、キータだぞー (768レス)
Qiita 7 - キータぞ、来たぞ、キータだぞー http://mevius.5ch.io/test/read.cgi/tech/1757733847/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
232: デフォルトの名無しさん [sage] 2025/10/02(木) 08:24:53.30 ID:3AP3Ig0g print関数はさすがに説明の便宜のためでしょ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/232
233: デフォルトの名無しさん [] 2025/10/02(木) 08:26:48.25 知りたいgithubのアドレスを取得 https://github.com/python/cpython アドレスのgithubをdeepwikiに置換 https://deepwiki.com/python/cpython 最下部のフォームに質問すればソースコードをソースにして回答する http://mevius.5ch.io/test/read.cgi/tech/1757733847/233
234: デフォルトの名無しさん [] 2025/10/02(木) 08:29:36.47 で このdeepwikiもMCPでアクセスできるので AIエージェントがコーディングのお作法を実装前にDeepWiki MCPで確認してソースコードをソースにして手順を確立してメモしてからそれを見ながら実装を開始するように出来る 低スキルエンジニア同士の会話など害しかない http://mevius.5ch.io/test/read.cgi/tech/1757733847/234
235: デフォルトの名無しさん [sage] 2025/10/02(木) 08:45:54.05 ID:6BvO5ATM 速さ優先ならこれとはまた異なってくるのだろう return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0) http://mevius.5ch.io/test/read.cgi/tech/1757733847/235
236: デフォルトの名無しさん [sage] 2025/10/02(木) 13:03:09.54 ID:sP1LMqCx return False http://mevius.5ch.io/test/read.cgi/tech/1757733847/236
237: デフォルトの名無しさん [sage] 2025/10/02(木) 13:37:06.50 ID:dLU/Z4Pm > それ、問題文の条件のまま書いちゃダメなんですよね。 > 「ただし」がある場合は前出の条件を否定してくるので、条件の順番通りに書くと破綻します。 > だから、「ただし」がある場合は条件を逆に記述していくのが鉄則です。 ashworthさん、何言ってんの? http://mevius.5ch.io/test/read.cgi/tech/1757733847/237
238: デフォルトの名無しさん [] 2025/10/02(木) 23:03:29.56 ID:jdy8/BVE >>219 これまでの書き込みからお前はRust信者と推測されるが、「言語仕様で明確に定義されているのに数学につられて 間違えるのは低学歴・無職・猿」という煽り文句がブーメランになることに気づいていないのか? C, C++ではif (a = b)という書き方が許されているが、数学では=が比較にも使われるため、比較するつもりで if (a = b)とうっかり書き間違え、読み返しても間違いを見落とす恐れがあるので、C#やRustではこういう書き方を できなくした。お前の煽り文句に従えば、代入は=、比較は==と言語仕様で明確に区別して定義されているのに 数学につられて間違えるのは低学歴・無職・猿で、C#やRustは低学歴・無職・猿向けの言語ってことになるねw 仮にお前がRustでなく他の言語の信者だとしても、似たようなブーメランを見つけることができるだろう。 Rustは他にも変数宣言でmutをいちいち書かせるなど過保護な安全性が設計思想にあるのに、半開区間..では 危うさを放置するのはチグハグだな。 あと、ここはプログラマー板じゃなくてプログラム板だから、別に職業プログラマ向けというわけではなく、 プログラムに関する見識は職を得ることに結びつかない。職業プログラマなんてIT土方とも揶揄されて 威張れるもんじゃないし、まして特定の言語と一蓮托生で必死になってるようではなー。お前の煽り文句は 明後日の方を向いているw http://mevius.5ch.io/test/read.cgi/tech/1757733847/238
239: デフォルトの名無しさん [] 2025/10/02(木) 23:03:54.24 ID:jdy8/BVE >>223 ユーザーは区間の記法だけによってどの言語を使うか選んでいるわけではないから、一概には言えない。 Pythonはずぼらだからはびこってしまった。あんな害蛇はさっさと駆除すべきだな。その点、Rustは 繁文縟礼の塊なのであまり普及せず実害は少ない。 C#はユーザーを十分獲得した後の2019年に半開区間..を初めて導入した。.NET兄弟のF#とPowerShellが ..を閉区間に既に割り当てていたのに、そして開発責任者はPascalと縁が深いのに、何であんな変な記法を 許してしまったの解せない。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/239
240: デフォルトの名無しさん [] 2025/10/02(木) 23:12:57.09 >>238 いやRustなんか興味ないし知らん どうでもいい 脳障害は日本語すら読めないだけ 人間は間違えないので猿を雇わなければ良いだけ 猿のために人間のルールを変えるわけない http://mevius.5ch.io/test/read.cgi/tech/1757733847/240
241: デフォルトの名無しさん [sage] 2025/10/03(金) 00:09:20.16 ID:Q1aE47Vx 半開区間に左右非対称を採用してる言語はSwiftだけじゃね? 半開区間の記法 【start:end】 Go Python 【start..end】C# Rust Zig 【start...end】Ruby 【start..<end】Swift この現状で左右対称を採用している言語はダメだと叩いている人は偏った異端者かと http://mevius.5ch.io/test/read.cgi/tech/1757733847/241
242: デフォルトの名無しさん [sage] 2025/10/03(金) 01:07:33.20 ID:aYxPE6CF 1991 Python 1995 Ruby 2000 C# 2009 Go 2010 Rust 2014 Swift 2015 Zig 後発の方が先達の反省が活かされた洗練された記法を採用してる可能性は普通に考えられるかな http://mevius.5ch.io/test/read.cgi/tech/1757733847/242
243: デフォルトの名無しさん [sage] 2025/10/03(金) 01:23:00.07 ID:Q1aE47Vx C#が半開区間start..endを導入したのは2019年リリースのC# version 8.0 http://mevius.5ch.io/test/read.cgi/tech/1757733847/243
244: デフォルトの名無しさん [sage] 2025/10/03(金) 08:33:47.40 ID:qYL3CF1r 『Cなら知ってるんですけど、C++ってできますか?』 Cた間違い http://mevius.5ch.io/test/read.cgi/tech/1757733847/244
245: デフォルトの名無しさん [sage] 2025/10/03(金) 08:35:11.18 ID:qYL3CF1r CやC++初心者は間違い探し的に読むと良い記事。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/245
246: デフォルトの名無しさん [sage] 2025/10/03(金) 10:41:32.04 ID:WGTRKW6c >>244 モダンC++と言いつつ大昔の古臭いC++11で草 さらにC++11と言いつつ中核のスマートポインタを割愛で草 http://mevius.5ch.io/test/read.cgi/tech/1757733847/246
247: デフォルトの名無しさん [] 2025/10/03(金) 11:02:03.70 ID:gMkT4O8N 長文おぢウザい http://mevius.5ch.io/test/read.cgi/tech/1757733847/247
248: デフォルトの名無しさん [] 2025/10/03(金) 23:27:23.05 ID:DEcBymr7 >>241 >>211に挙げた「両方ある」の7言語のうち「半開区間に左右対称記号を使用」の3言語を除いた4言語、 つまりKotlin, Nim, Raku, Swiftが半開区間に左右非対称の記号を使用している(Kotlin, Nim, Swiftは ..<で、Rakuは...^)。Rakuには左半開区間^...と開区間^...^もあり、4種類すべての区間を書ける。 これらに含まれる...は…と1文字で書いても良い。 Rubyは閉区間..より半開区間...の方が長いから、>>165がやたらこだわっている情報理論的効率性とやらには 反しているな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/248
249: デフォルトの名無しさん [sage] 2025/10/03(金) 23:28:02.03 ID:ft8WeviY >>238 > 変数宣言でmutをいちいち書かせるなど これはプログラマーに mutable宣言を意味するmutなどを書かせるべきか immutable宣言を意味するconstなどを書かせるべきか どちらをデフォルトにすべきかという問題だね これはimmutableのみが許されてmutableを許さないプログラミング言語もあるくらいで immutableをデフォルトとして必要不可欠な変数のみmutable宣言させるのが正しいと思われる プログラマーの手間もその方が少ない http://mevius.5ch.io/test/read.cgi/tech/1757733847/249
250: デフォルトの名無しさん [sage] 2025/10/04(土) 14:05:10.36 ID:eyfPTg37 Qiita Conference 2025 Autumn というので https://qiita.com/official-campaigns/conference/2025-autumn > 今のコンピュータはAIにもWebにも向いていないので作り直そう > 2018年にAttentionが発表され、2022年末にLLMが登場して以降、GPUを用いた生成AIがあらゆるコンピューティングの活用を塗り替えていますが、実はGPUが生成AIに向いていないことをご存知でしょうか? > 他にも、現代コンピュータアーキテクチャ自体が約70年前に構想されて以来、スループット/レイテンシ/電力消費に根本的な課題を抱えたままで、WebやIoTなどの大量ユーザー利用/データ利用と言った現代に求められる様々は「エンジニアが無理やり何とかしている」と言う実態があります。 > こうした課題を生み出す裏側を解説した後、性能と省電力を圧倒的に引き上げるための考え方/イノベーションを共有し、実際の解決実装例をご紹介します。 コイツに講演させちゃうんだなあ。ゲスト講演ということだけどどうやって人選してるのだろう? http://mevius.5ch.io/test/read.cgi/tech/1757733847/250
251: デフォルトの名無しさん [] 2025/10/04(土) 19:45:26.17 >>250 課題を生み出すwwww 省電力を引き上げるwwwww これだけで価値がないとわかる http://mevius.5ch.io/test/read.cgi/tech/1757733847/251
252: デフォルトの名無しさん [sage] 2025/10/04(土) 21:38:51.49 ID:MpcY569I >>250 山崎かなと思ったら福岡Elixirって書いてあったから同族か http://mevius.5ch.io/test/read.cgi/tech/1757733847/252
253: デフォルトの名無しさん [sage] 2025/10/04(土) 23:29:54.72 ID:gLEEZL45 >immutableのみが許されてmutableを許さないプログラミング言語もあるくらいで マイナーな言語しかなくね? 「そういう言語がある」だけで、多くの人にとってはそれが便利だと思われてないと思うぞ http://mevius.5ch.io/test/read.cgi/tech/1757733847/253
254: デフォルトの名無しさん [sage] 2025/10/04(土) 23:33:11.13 ID:qAgFTJKW Elixirの軽量スレッドで並列処理が効率化できてスパコン的用途にも使えると思ってる人たちだからなあ、つける薬がない。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/254
255: デフォルトの名無しさん [sage] 2025/10/04(土) 23:59:14.21 ID:XZN99/my >>253 immutableだけだと不便で制限が生じる その一方でプログラムはなるべくimmutableを中心にしてmutableは補助的に使うと良いコードになる http://mevius.5ch.io/test/read.cgi/tech/1757733847/255
256: デフォルトの名無しさん [sage] 2025/10/05(日) 23:10:55.15 ID:W6M3iXcI Elixirでフィボナッチ数列をいろいろ書いてみた Part. 5 https://qiita.com/zacky1972/items/1d2dd390454e80f39d3f > Fibonacci with Matrix は素晴らしく速いですね! Elixirで順に指定個数の素数を列挙する関数をEnum, Stream, Flowで作ってみた https://qiita.com/zacky1972/items/2cdc68f56c2b42b803e1 > 1000,10000個の時にはFlowが最速でした. 1000番目のフィボナッチ数計算すんのに 1.33m秒とか、ベンチマーク結果なんでか編集で消えてるんだけど > prime_flow 11.84 84.48 ms ±1.22% 84.27 ms 89.85 ms 20000未満の素数算出すんのに 84m秒って遅すぎね? 福岡Elixirってこんな記事ばっかりだな。んで、身内でいいね付けあってる。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/256
257: デフォルトの名無しさん [] 2025/10/05(日) 23:41:25.21 スキルがあるのに福岡なんかにある仕事の給料で耐えられるわけない http://mevius.5ch.io/test/read.cgi/tech/1757733847/257
258: デフォルトの名無しさん [sage] 2025/10/06(月) 00:44:13.25 ID:3OKVU+gM >>256 > 20000未満の素数算出すんのに 84m秒って遅すぎね? ベンチマーク出すのに84m秒って速すぎね? 84m秒のベンチマークを100回やるのがいいのか8.4秒のベンチマークを1回やるのがいいのかで遅いほうがいいと思うんだが http://mevius.5ch.io/test/read.cgi/tech/1757733847/258
259: デフォルトの名無しさん [sage] 2025/10/06(月) 01:20:13.00 ID:bQ0ntySb フィボナッチ数は行列累乗を理解してないから乗数の数だけ掛け算やってるし、素数の方は「エラトステネスのふるいを純朴に利用して」と書いてる割に剰余計算で余りがでたものを倍数としてフィルタする処理になってて全然エラトステネスのふるいじゃないなあ、ダメだこりゃ。 どちらの記事もアルゴリズムへの理解がなくて効率悪いことやってるんだが、こういう記事平気で公開してる人が 地球温暖化とコンピュータのエネルギー消費の問題にElixirで立ち向かう〜「コンピュータと地球温暖化は 決して無縁ではない」(2022年版) https://qiita.com/zacky1972/items/a67459bf36f7b369b946 なんて記事書いてて頭が痛い。 これで大学の先生ってなあ、冗談なら良いのに。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/259
260: デフォルトの名無しさん [] 2025/10/06(月) 01:25:15.29 ID:bQ0ntySb >>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 http://mevius.5ch.io/test/read.cgi/tech/1757733847/260
261: デフォルトの名無しさん [sage] 2025/10/06(月) 06:36:07.31 ID:53QY0HCL >>259 エラトステネスのふるいは、 作業メモリをその数だけ必要とすることと引き換えに、 足し算だけで素数を求めることができるアルゴリズムだから、 遅い剰余算を用いた時点で失格となりますね。 エラトステネスのふるいの場合をベンチマークとして比較しているわけでもないようてすね。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/261
262: デフォルトの名無しさん [sage] 2025/10/06(月) 08:49:11.07 ID:0Xz/SJfu この先生はElixirみたいなニッチな言語研究するより先にアルゴリズムの勉強したほうが良いと思う。 現状では学部の学生並みの知識もある気がしない。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/262
263: デフォルトの名無しさん [sage] 2025/10/09(木) 14:36:21.61 ID:/RUFLlG7 『【C言語】char型の落とし穴~オーバーフロー~』 charの変数の値はintに昇格されてから加算されるのでこの場合オーバーフローしないし、intからcharに型変換する際にビットが捨てられるのもオーバーフローじゃないけど、この記事は何をオーバーフローと呼んでいるのか? http://mevius.5ch.io/test/read.cgi/tech/1757733847/263
264: デフォルトの名無しさん [sage] 2025/10/09(木) 15:40:17.99 ID:KD7T9yPY Cしか使えない特殊な環境ならともかく 勝手に異なる型へ自動変換されて困ったことになる弱い型付け言語のCを使ってる情弱の知識はそんなもんだ http://mevius.5ch.io/test/read.cgi/tech/1757733847/264
265: デフォルトの名無しさん [sage] 2025/10/10(金) 00:22:23.86 ID:SqpOO1WH https://qiita.com/GonT38847064/items/0770153fd0fb05abaa8a#comment-b7ef583e34653899a04a > ご指摘ありがとうございます。数値を修正しました... コンパイルエラーが出るよう修正するとかw https://gcc.godbolt.org/z/565sb5PEh http://mevius.5ch.io/test/read.cgi/tech/1757733847/265
266: デフォルトの名無しさん [sage] 2025/10/10(金) 01:56:58.97 ID:3qfmD/kK 今となっては未定義動作だらけの欠陥言語Cにこだわる人はほぼ異常者だな 残りは特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ http://mevius.5ch.io/test/read.cgi/tech/1757733847/266
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 >条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。 >そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。 知らないこと想像で書いてて大変宜しいw 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 実例挙げられない辺りが限界なんだろうなあw 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 どのコンパイラがどういうコード吐いてるかも示せないで実例とか言ってるのはたまげたなw 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 オーバーフローを無視して処理を続けていいわけはないので安全性の話なんだよなあ 何言ってんのこの人w 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 配列アクセスで範囲チェックしてくれる言語についてオーバーフローチェックは「効率ガー」と発狂してるのオモロイw お前らRustも実行効率もなんも分かってないなw 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
メモ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 437 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.852s*