Qiita 7 - キータぞ、来たぞ、キータだぞー (765ﾚｽ)
上下前次1-新
201(1): 2025/09/30(火)11:06 ID:EJn4wwZL(2/2) AAS
いまはこのルールでやりましょうというグレゴリオ暦を分かってないｗ
202(1): 2025/09/30(火)12:34 ID:dVe563is(1) AAS
グレゴリオ暦のうるう年の判定ルール
・西暦年が4で割り切れる年はうるう年となる
・ただし、西暦年が100で割り切れる年はうるう年としない
・さらに、西暦年が400で割り切れる年は例外的にうるう年とする
203: 2025/09/30(火)12:39 AAS
低学歴がなぜ低学歴なのかよくわかる
204: 2025/09/30(火)12:40 AAS
>>201
バカすぎてルールを理解できないことを正当化するためにルールがおかしいと吠えたまま死ぬ
これが低学歴の人生
205: 2025/09/30(火)12:40 AAS
そういうゴミクズを雇ったら終わりなので学歴システムがある
人間判定試験
猿を雇わないようにするための仕組み
206(1): 2025/09/30(火)23:54 ID:gehVEPsn(1) AAS
>>188
閉区間ではなく半開区間をサポートするプログラミング言語が多い理由を考えてみよう
それらの言語は半開区間に左右非対称の記号ではなく簡潔な記号を割り当てている理由を考えてみよう
207(2): 2025/10/01(水)00:59 AAS
算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は
208: 2025/10/01(水)01:38 ID:Fskx/ZBj(1) AAS
> そもそも自転はずれるからな
地球の自転周期が変わったとして影響があるのは1日の長さなんだがｗ
209: 2025/10/01(水)02:15 ID:VkTjow7K(1) AAS
>>207
多用する半開区間に短い記号を充てるのが正解だと思う
しかしPythonやGoの start:end はあまりにも短すぎて用いる場所によっては文法的に曖昧になる可能性があるためなのか
現状はスライスのインデックス部分 a[start:end] でしか用いることができない
例えばmatch文のcaseでは指定できないため case x if start <= x < end と書く必要がある
イテレータとしても指定できないため for i in range(start, end) と書く必要がある
これら全て同じ記法で書けると好ましい
210: 2025/10/01(水)21:52 ID:yE7SMjvb(1) AAS
Rustは同じ扱い
buf[100..200]
for i in 100..200 { … }
match x {
100..200 => …,
…
}
211(3): 2025/10/01(水)23:34 ID:a34LDfpM(1/3) AAS
AA省
212(2): 2025/10/01(水)23:35 ID:a34LDfpM(2/3) AAS
>>207
圧縮ファイルを直読みできる超人さんですか?w
短さを馬鹿の一つ覚えみたいに持ち出しているが、間違えにくさを犠牲にしてまで達成すべきものではない。
人間は機械ではないのでうっかり間違えやすい記号を宛てないのが賢明で、たった1文字をケチるのは愚行。
正確に言えば機械も生の状態では間違えるから、エラー訂正符号を付加して無謬に見せかけているだけなので、
人間にも機械にも最短ではなくそれぞれの間違え方を防ぐような追加の情報も必要だという訓戒に纏められるな。
そこを疎かにするのは欠陥設計。
213: 2025/10/01(水)23:36 AAS
>>211
算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は
214(1): 2025/10/01(水)23:37 AAS
>>212
え？圧縮ファイル？
何言ってんのこの中卒無職脳障害
そんなの関係ねえよ猿が
情報理論的な効率性の話しかしてないのに中卒だからわかんねえのか自殺しとけ猿が
215: 2025/10/01(水)23:38 AAS
>>212
お前が低学歴で人間じゃないだけ
お前は無職で人間の世界から排除されてるから人間の世界に口出しする権利ないよ
参加お断り
216(4): 2025/10/01(水)23:51 ID:a34LDfpM(3/3) AAS
>>214
馬鹿には皮肉の解説が必要だったか。情報理論的な効率性を徹底的に追求したのが圧縮ファイルだろ。
それは人間には勿論読めないが、もう少し緩く追求した半開区間に..を使う表記も人間にはやっぱり
間違いやすい。お前がそんなことはないと言い張るなら、さぞかし凄い超人なんだろうねーという皮肉。
たった1文字追加するだけで効率性と間違えにくさのバランスが取れた表記になるのに、ムキになって
否定するのは愚か。
217: 2025/10/01(水)23:56 AAS
>>216
圧縮ファイルなんて使ってない
人間の世界では最短符号を使って人間は読んでる
無職はそれが読めないから誰も雇わない
218: 2025/10/01(水)23:56 AAS
>>216
お前が間違えてもどうでもいい
だってお前は人間じゃないし人間の社会に参加出来ないから
219(1): 2025/10/01(水)23:57 AAS
>>216
人間は間違えない
猿は間違える
だから猿を雇わない
よってお前は無職
猿だからな
220: 2025/10/02(木)00:00 ID:IXGrVOcw(1) AAS
>>216
C#の半開区間指定start..end読みやすくて良いと思うよ
閉区間だと間違える人はいない
221: 2025/10/02(木)00:02 AAS
人間は間違えない
猿は間違える
だから猿を雇わなきゃいいだけ
222: 2025/10/02(木)00:02 AAS
猿に合わせて人間のルールを変えるわけねえだろ
猿を排除するのが最善
223(1): 2025/10/02(木)00:44 ID:Jz40Wv3H(1) AAS
>>211
それら閉区間しかないプログラミング言語は現代のメジャーな言語ではないな
センスが悪いとメジャーな言語になれないことがわかった
224(1): 2025/10/02(木)01:12 ID:EU/7mSn/(1) AAS
>>202
『あなたは本当に「プログラミングができない、向いてない」のか？ 〜うるう年判定プログラムで考える〜』
外部ﾘﾝｸ:qiita.com
という記事のコメ欄でashworthが他のコメントに絡んでたけど(垢BAN済み)、記事のコード見ると
> year = int(input())
> if year % 400 == 0: # 400の倍数なら「うるう年です。」
> print("うるう年です。")
> elif year % 100 == 0: # 100の倍数なら「うるう年ではありません。」
> print("うるう年ではありません。")
> elif year % 4 == 0: # 4の倍数なら「うるう年です。」
省5
225: 2025/10/02(木)01:14 ID:qLX1OCT3(1) AAS
まともな言語がいずれも半開区間をサポートしているのは偶然ではなくて、
配列やリストやベクタあるいは文字列などの連続領域の一部分いわゆるスライスを言語で扱おうとすると、
その区間を指定する必要がでてくる。
まともな汎用言語ならそのスライスと区間指定をサポートするのは必然で、
しかも閉区間は扱いにくいことが判明しているわけだから、
結果的に半開区間をサポートしているか否かでまともな言語か否かが判明することになっている。
226(1): 2025/10/02(木)04:38 ID:oFFK8/LC(1) AAS
>>224のコードってそんなに変かな？ 自分もこんな感じに書くと思うが。
227: 2025/10/02(木)05:00 ID:vDXY/c5t(1) AAS
>>226
動くコードは無数に考えられる。
しかし保守性を考慮すると、
元の文章に対応したコードのみが正解。
元の文章と逆順に書いた場合、
何か理由が添えてない限り失格でクビだろうね。
228: 2025/10/02(木)07:15 AAS
ソース読めよ
Check out this DeepWiki page 外部ﾘﾝｸ:deepwiki.com
229: 2025/10/02(木)07:34 ID:3AP3Ig0g(1/2) AAS
なるほど、if文のネストみたいな感じで書くのだとしたらそれはかえって分かりにくいのではと思ったけど、and or で1行で書いちゃうならスッキリしているね。
230: 2025/10/02(木)08:18 AAS
if文使った時点で不採用
print文使った時点で不採用
正解は
・数式・比較演算子と論理演算子で書く
・デバッガで各論理式の評価を確認してprint文を使わない
231: 2025/10/02(木)08:19 AAS
deepwikiでソースコードに聞け
低スキルの「エンジニア」同士で低スキルを伝播しても害しかない
232: 2025/10/02(木)08:24 ID:3AP3Ig0g(2/2) AAS
print関数はさすがに説明の便宜のためでしょ。
233: 2025/10/02(木)08:26 AAS
知りたいgithubのアドレスを取得
外部ﾘﾝｸ:github.com
アドレスのgithubをdeepwikiに置換
外部ﾘﾝｸ:deepwiki.com
最下部のフォームに質問すればソースコードをソースにして回答する
234: 2025/10/02(木)08:29 AAS
で
このdeepwikiもMCPでアクセスできるので
AIエージェントがコーディングのお作法を実装前にDeepWiki MCPで確認してソースコードをソースにして手順を確立してメモしてからそれを見ながら実装を開始するように出来る
低スキルエンジニア同士の会話など害しかない
235: 2025/10/02(木)08:45 ID:6BvO5ATM(1) AAS
速さ優先ならこれとはまた異なってくるのだろう
return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
236: 2025/10/02(木)13:03 ID:sP1LMqCx(1) AAS
return False
237: 2025/10/02(木)13:37 ID:dLU/Z4Pm(1) AAS
> それ、問題文の条件のまま書いちゃダメなんですよね。
> 「ただし」がある場合は前出の条件を否定してくるので、条件の順番通りに書くと破綻します。
> だから、「ただし」がある場合は条件を逆に記述していくのが鉄則です。
ashworthさん、何言ってんの?
238(2): 2025/10/02(木)23:03 ID:jdy8/BVE(1/2) AAS
>>219
これまでの書き込みからお前はRust信者と推測されるが、「言語仕様で明確に定義されているのに数学につられて
間違えるのは低学歴・無職・猿」という煽り文句がブーメランになることに気づいていないのか?
C, C++ではif (a = b)という書き方が許されているが、数学では=が比較にも使われるため、比較するつもりで
if (a = b)とうっかり書き間違え、読み返しても間違いを見落とす恐れがあるので、C#やRustではこういう書き方を
できなくした。お前の煽り文句に従えば、代入は=、比較は==と言語仕様で明確に区別して定義されているのに
数学につられて間違えるのは低学歴・無職・猿で、C#やRustは低学歴・無職・猿向けの言語ってことになるねw
仮にお前がRustでなく他の言語の信者だとしても、似たようなブーメランを見つけることができるだろう。
Rustは他にも変数宣言でmutをいちいち書かせるなど過保護な安全性が設計思想にあるのに、半開区間..では
危うさを放置するのはチグハグだな。
省4
239: 2025/10/02(木)23:03 ID:jdy8/BVE(2/2) AAS
>>223
ユーザーは区間の記法だけによってどの言語を使うか選んでいるわけではないから、一概には言えない。
Pythonはずぼらだからはびこってしまった。あんな害蛇はさっさと駆除すべきだな。その点、Rustは
繁文縟礼の塊なのであまり普及せず実害は少ない。
C#はユーザーを十分獲得した後の2019年に半開区間..を初めて導入した。.NET兄弟のF#とPowerShellが
..を閉区間に既に割り当てていたのに、そして開発責任者はPascalと縁が深いのに、何であんな変な記法を
許してしまったの解せない。
240: 2025/10/02(木)23:12 AAS
>>238
いやRustなんか興味ないし知らん
どうでもいい
脳障害は日本語すら読めないだけ
人間は間違えないので猿を雇わなければ良いだけ
猿のために人間のルールを変えるわけない
241(1): 2025/10/03(金)00:09 ID:Q1aE47Vx(1/2) AAS
半開区間に左右非対称を採用してる言語はSwiftだけじゃね？
半開区間の記法
【start:end】 Go Python
【start..end】C# Rust Zig
【start...end】Ruby
【start..<end】Swift
この現状で左右対称を採用している言語はダメだと叩いている人は偏った異端者かと
242: 2025/10/03(金)01:07 ID:aYxPE6CF(1) AAS
1991 Python
1995 Ruby
2000 C#
2009 Go
2010 Rust
2014 Swift
2015 Zig
後発の方が先達の反省が活かされた洗練された記法を採用してる可能性は普通に考えられるかな
243: 2025/10/03(金)01:23 ID:Q1aE47Vx(2/2) AAS
C#が半開区間start..endを導入したのは2019年リリースのC# version 8.0
244(1): 2025/10/03(金)08:33 ID:qYL3CF1r(1/2) AAS
『Cなら知ってるんですけど、C++ってできますか？』
Cた間違い
245: 2025/10/03(金)08:35 ID:qYL3CF1r(2/2) AAS
CやC++初心者は間違い探し的に読むと良い記事。
246: 2025/10/03(金)10:41 ID:WGTRKW6c(1) AAS
>>244
モダンC++と言いつつ大昔の古臭いC++11で草
さらにC++11と言いつつ中核のスマートポインタを割愛で草
247: 2025/10/03(金)11:02 ID:gMkT4O8N(1) AAS
長文おぢウザい
248: 2025/10/03(金)23:27 ID:DEcBymr7(1) AAS
>>241
>>211に挙げた「両方ある」の7言語のうち「半開区間に左右対称記号を使用」の3言語を除いた4言語、
つまりKotlin, Nim, Raku, Swiftが半開区間に左右非対称の記号を使用している（Kotlin, Nim, Swiftは
..<で、Rakuは...^）。Rakuには左半開区間^...と開区間^...^もあり、4種類すべての区間を書ける。
これらに含まれる...は…と1文字で書いても良い。
Rubyは閉区間..より半開区間...の方が長いから、>>165がやたらこだわっている情報理論的効率性とやらには
反しているな。
249: 2025/10/03(金)23:28 ID:ft8WeviY(1) AAS
>>238
> 変数宣言でmutをいちいち書かせるなど
これはプログラマーに
mutable宣言を意味するmutなどを書かせるべきか
immutable宣言を意味するconstなどを書かせるべきか
どちらをデフォルトにすべきかという問題だね
これはimmutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
immutableをデフォルトとして必要不可欠な変数のみmutable宣言させるのが正しいと思われる
プログラマーの手間もその方が少ない
250(2): 2025/10/04(土)14:05 ID:eyfPTg37(1) AAS
Qiita Conference 2025 Autumn というので
外部ﾘﾝｸ:qiita.com
> 今のコンピュータはAIにもWebにも向いていないので作り直そう
> 2018年にAttentionが発表され、2022年末にLLMが登場して以降、GPUを用いた生成AIがあらゆるコンピューティングの活用を塗り替えていますが、実はGPUが生成AIに向いていないことをご存知でしょうか？
> 他にも、現代コンピュータアーキテクチャ自体が約70年前に構想されて以来、スループット／レイテンシ／電力消費に根本的な課題を抱えたままで、WebやIoTなどの大量ユーザー利用／データ利用と言った現代に求められる様々は「エンジニアが無理やり何とかしている」と言う実態があります。
> こうした課題を生み出す裏側を解説した後、性能と省電力を圧倒的に引き上げるための考え方／イノベーションを共有し、実際の解決実装例をご紹介します。
コイツに講演させちゃうんだなあ。ゲスト講演ということだけどどうやって人選してるのだろう?
251: 2025/10/04(土)19:45 AAS
>>250
課題を生み出すwwww
省電力を引き上げるwwwww
これだけで価値がないとわかる
252: 2025/10/04(土)21:38 ID:MpcY569I(1) AAS
>>250
山崎かなと思ったら福岡Elixirって書いてあったから同族か
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
オーバーフローを無視して処理を続けていいわけはないので安全性の話なんだよなあ
何言ってんのこの人ｗ
上下前次1-新書関写板覧索設栞歴
あと 465 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.044s