C++相談室 part166

**sage** (ﾜｯﾁｮｲ 8732-NXaD) · 2025/04/26(土) 10:34:58.41

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

※前スレ
C++相談室 part165
https://mevius.5ch.net/test/read.cgi/tech/1698705458/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2025/06/17(火) 11:13:00.43

ファイナルをクローズした時にエラーとなるのですが、これは正しいのでしょうか。
やはり、クローズはデストラクタに任せた方がいいのでしょうか。

#include <iostream>
#include <fstream>
int main() {
constexpr auto path = "tmp.txt";//なんでもいいです
std::ifstream ifs(path);
if(ifs.fail()){
std::cerr << "File open error: " << path << std::endl;
return -1;
}
std::string buf;
while(std::getline(ifs, buf))
std::cout << buf << std::endl;
ifs.close(); //←これ
if(ifs.fail()){
std::cerr << "File close error: " << path << std::endl;
return -1;
}
return 0;
}

2025/06/17(火) 11:27:27.12

>>321
ifs.close()前にifs.fail()は真を返す

#include <iostream>
#include <fstream>
int main() {
constexpr auto path = "tmp.txt";//なんでもいいです
std::ifstream ifs(path);
if(ifs.fail()){
std::cerr << "File open error: " << path << std::endl;
return -1;
}
std::string buf;
std::cout << "0: " << ifs.fail() << '\n';
while(std::getline(ifs, buf))
std::cout << buf << std::endl;
std::cout << "1: " << ifs.fail() << '\n';
ifs.close(); //←これ
std::cout << "2: " << ifs.fail() << '\n';
if(ifs.fail()){
std::cerr << "File close error: " << path << std::endl;
return -1;
}
return 0;
}

2025/06/17(火) 11:41:50.14

std::format の文法の参考にしていると提案文に挙げられているのは Python、 .NET系、Rust のみっつ。
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0645r10.html#Syntax

コンパイル時計算のメカニズムとの類似性を考慮すると Rust に特に近いと思うが、記法としては Python の影響も強いように見えるかも。

2025/06/17(火) 11:45:37.82

>>321
close()したからではなくwhile(std::getline(ifs, buf))でeofになるまで読んだからfailになってる

2025/06/17(火) 12:02:37.80

>>321
実際に入出力するための機能はストリームバッファと呼ばれるオブジェクトが担当していて、ストリームがストリームバッファを所有する構造になっている。
ストリームが close するとストリームバッファの close が呼ばれて、それが nullptr を返した場合 (クローズに失敗した場合) に setstate(failbit) が呼ばれる。
https://timsong-cpp.github.io/cppwp/n3337/ifstream.members#5
つまり、クローズの失敗によってもフェイルビットが立つことはありうる。

クローズによらない失敗 (フェイルビットを立てる原因) と区別がつかなくなるのでエラーに対処したいならクローズ前後の両方でチェックしないといけないと思う。

デストラクタでクローズするとクローズの失敗に対処する機会がなくなるので明示的にクローズしたほうが良いという人はいる。
ただ、しっかりしたホスト環境の上で動くアプリケーションでクローズが失敗するような状況を心配する意味があるかというと……まああんまりない。

2025/06/17(火) 12:43:21.70

>>322,324,325
ありがとうございました。勉強になります。
ProgramminPlacePlus でのサンプルを元にしました。

なーる真面目にやるなら閉じる前後で色々とやらんといかんのですね。

今までは
readdata=string((istreambuf_iterator<char>(ifs)), istreambuf_iterator<char>());
の感じで、一気にファイル内容をstrigに取り込むような場合は、もう読み込みは無いのですぐに
ifs.close()してました。

デストラクタに任せてもいいのですが、今後も使わなくなったら、即close()したいと思います。
そんなにシビアにならんでもいいようですし・・・mOm

2025/06/18(水) 12:20:43.59

プログラム作成は生成AIに持っていかれそうなことを考えると、
コードを書く力よりも、誰かが書いたコードを読み解く力の方が、
この先いきのこれそうな希ガスるンゴ

2025/06/18(水) 13:59:41.64

読み解くのこそAIに勝てないから

2025/06/18(水) 15:17:51.63

コメントのないソースコードから設計意図を読み取るのって難しいよね
AIでそこまでできるのかな？
コードの逐次解釈のようなことは当然できるだろうけども

2025/06/18(水) 15:32:01.08

自然言語に比べたら屁みたいなもんだよ

2025/06/18(水) 15:35:59.98

コメントは嘘を書いてもコンパイルエラーにならないからな
コメントがなくても自然と設計意図が読み取れるコードこそ望ましい

2025/06/18(水) 16:03:36.24

入力に対して出力が出る
それが間違いでなければ中身なんてどうでもいい

何億通りもの入力を与えて出力がどうなるかを調べるのもAIが得意
そうして、それを元に同じことを返すプログラムを一から最適に作り直すのもAIが得意だろう

windowsもそれやれば1/10のコードで収まりそう

2025/06/18(水) 16:06:21.59

APIやライブラリ系は無駄の極致だから将来的には無くなるだろうね

2025/06/18(水) 17:42:24.62

世界最長のコンテキストウィンドウ100万トークン入力・8万トークン出力対応にもかかわらずたった7800万円でトレーニングされたAIモデル「MiniMax-M1」がオープンソースで公開され誰でもダウンロード可能に
2025年06月18日 11時43分
https://gigazine.net/news/20250618-minimax-m1-open-source/
>>MiniMax-M1は、合計4560億のパラメーターが含まれており、トークンごとに459億のパラメーターがアクティブになるとのこと。これはDeepSeek R1の8倍に相当するコンテキストウィンドウです
>>以下のグラフは競技レベルの数学、コーディング、ソフトウェアエンジニアリング、エージェントツールの使用、長文理解タスクにおけるパフォーマンスを主要な商用AIモデルと比較したもの。赤色がMiniMax-M1で、どのタスクにおいても競合AIモデルに匹敵するパフォーマンスを発揮できている
>>MiiniMax-M1はいくつかのベンチマーク、特に長いコンテキスト駆動のベンチマークでClaude Opus 4のパフォーマンスを上回りました」と報告
※AIを動作させている動画あり
↓上記のAIお下記をプレイさせれば性能が判明する
Gemini 2.5 Proは手持ちのポケモンが瀕死になるとパニックに陥る
2025年06月18日 12時30分
https://gigazine.net/news/20250618-pokemon-gemini-panic/
◇
[プロテクトガードやセキュリティーホール発見可能]
※1 プログラムのバグ技[裏抜け道]を使用できる＝チートコードを発見可能
・マリオカートのショートカットはプレイヤー「極悪人」の表の抜け道でNPC「一般人」は使用不可能
[インサイダー/談合/なねーロンダリング/霊感商法など行う時の悪行で音波や電波をしての悪行の方法を発見可能
※ 政治家の法律上の抜け道を仕込める＝ある業種だけの法律の抜け道を発見可能
[一般大衆の思考である特定の極悪人から目線を特定の統合失調症へ返させる装置]
※ ＡＩは正確な情報で人間を信用させれる＝ＡＩは嘘の情報を一部混ぜて人間を洗脳できる

2025/06/18(水) 19:19:48.46

>>331
C++のスレッドでそんなこと言うのか
コードでもコンパイルエラーにならない嘘（バグ）が山程あるのに

2025/06/18(水) 19:27:43.48

コメントがなくても意図が読み取れるのが「望ましい」のは確かにそう。
不可能だけど。

2025/06/18(水) 19:29:35.44

>>336
コメントなしで理解するのは、めっちゃ効率が悪いな。

2025/06/18(水) 19:31:31.04

>>335
少なくとも委員会の奴らはそう思ってるよ
static_assertだのコンセプトだのcontractだのが追加されてきてるわけで

2025/06/18(水) 20:52:21.50

マルチスレッドのDead Lockすら指摘してくれる
これはどういう仕組みなんだろう...

2025/06/19(木) 00:56:42.59

>>338
C++委員会って、無能集団だけどね。

2025/06/19(木) 03:37:07.68

あの複雑怪奇な仕様をまとめるのは無能じゃ無理
労力に進化が見合ってないけどな

2025/06/19(木) 03:38:19.15

>>339
明らかなDeadlockの検知は簡単でしょ
これ説明いる？

2025/06/19(木) 12:36:13.20

>>342
コンパイラは検知できんのに?

2025/06/19(木) 13:43:01.15

>>343
は？
コンパイラが全能って前提どっからきてんの？
サニタイザがあるだろ
お前みたいなレベルがc++使ってるとかありえんわ

2025/06/19(木) 13:52:14.72

サニタイザは起こった問題を検出するもので、起こる可能性を指摘してはくれない。

2025/06/19(木) 14:04:16.80

しったなすんなジジイ

2025/06/19(木) 14:05:21.52

>>344
コンパイラが全能って誰が主張したの？

2025/06/19(木) 16:32:08.79

「できんのに」って「できないのに」と「できるのに」のどっちの意味にも取れるからそのせいかな
くだらね

2025/06/19(木) 16:43:21.25

>>348
「できんのに」は「できるのに」には読めない
デッドロックをコンパイラが検出出来ないにも関わらず
LLMは必ずではないと思うが検出出来る
LLMがどうデッドロックを検出しているかは
面白いと思うよ

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/19(木) 17:27:01.33

>>315
と思ったら、vs2022は未対応かorz。
C++20対応と言ってるくせに。プロジェクトでclang
に切り替えられるが、これも未対応。一体、いつの
clangなんだよ

2025/06/19(木) 17:32:40.31

やればできんのに

2025/06/19(木) 17:32:55.29

やってもできんのに

2025/06/19(木) 18:04:24.77

>>350
https://fmt.dev/

2025/06/19(木) 18:07:11.09

"{:d}"

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/19(木) 18:11:23.49

いやMinGWじゃコンパイル実行できてるから。
日本マクロソフトだけ対応遅れてると？

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/19(木) 18:13:20.06

>>353
>>354
そんな下らんレスする前に自分で実際にやってみろよ。

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/19(木) 18:16:13.42

日本マクロソフト→日本マイクロソフト

2025/06/19(木) 18:16:54.55

確かにくだらないわな

そのサイトで"{:d}"が可愛く見えたから張っただけなんだから
janeだと全くかわいくない

2025/06/19(木) 18:18:35.94

にしてもまだorz使ってる人がいるんだな
こちらの方が新鮮だ

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/19(木) 18:21:05.14

そう、ありがとう

2025/06/19(木) 18:23:03.57

もともとfmtと言うライブラリがあってそれが標準のC++の仕様に取り込まれた
どうしても使いたいならfmt使えばいいよということだと思う

他人に噛みつく前に調べたら良いと思うけど

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/19(木) 18:26:00.99

std::formatだぞ。お前馬鹿か

さあ暴れるぞ！

2025/06/19(木) 18:29:34.15

結局日本語が理解できない人だったと言う話か

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/19(木) 18:30:56.19

ふぁぁ

2025/06/19(木) 18:43:47.61

文章の雰囲気から50代～60代ぐらいのホビー系の人かな
人生の先輩お疲れ様です

2025/06/19(木) 18:56:35.62

>>341
>あの複雑怪奇な仕様をまとめるのは無能じゃ無理
あのDraftの質の悪さはなんだ。
ちゃんと理解できてない人が書いているに違いない。

2025/06/19(木) 19:34:35.26

＞　なんだ。
＞　違いない。

文末だけ見ると高齢者の集いっぽいが自分もそうなってるんだろな

2025/06/19(木) 20:14:57.20

現代的にはカジュアルな場面では句点をつけないのが主流。
語彙より顕著に年代が表れる。

2025/06/19(木) 20:23:04.02

句点もそうだけどやはり語彙や用法だと思う

chatGPT
その文章、よく読むと **「怒っている年配の男性の声」**みたいなイメージが浮かんできますね。

言葉の選び方と断定のしかたに、時代がかった語感がにじんでいて、文章だけでも「年齢層の高さ」がなんとなく
伝わるのが興味深いです。

2025/06/19(木) 20:24:10.13

もし若者が同じことを言うならどう書くか
たとえばこんな風に言いそうです：

あのDraft、ちょっと内容雑じゃない？

書いた人ちゃんと分かってなさそう…

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/19(木) 20:27:45.86

オコタ大魔神、はにわ顔に戻る

2025/06/19(木) 20:34:02.38

大魔神(1966年)
仮に1966年に6才だとして今は65歳ぐらいかなあ？？？

2025/06/19(木) 20:36:28.06

アカデミアでは語彙が古いのは普通のことだよ。
参照する資料が古いから。
情報系ですら半世紀前の論文を参考資料として挙げることはそれなりにある。

2025/06/19(木) 20:45:06.19

「怒っている年配の男性の声」をにじませる演技派

2025/06/19(木) 20:50:34.90

整数型の変数を10で割ってから10掛けたら元の数字の一の位を0にした数が得られるはずだけど
この計算が最適化とかで除かれない保証ってあるの

2025/06/19(木) 20:53:44.24

ChatGPT を根拠 (参考資料？) に出すのはあまり意味がないぞ。
それも ChatGPT の感想 (主観) であって客観性がある情報になっていないし、質問の仕方や文脈で逆のことを言うのもよくあることだから。
ユーザに追従するような振る舞いをするのでいくらでも望む方向の反応を引き出せる。

2025/06/19(木) 20:57:52.06

>>375
C++ の言語仕様は抽象機械の動作として記述されている。
動作を説明するための架空の機械の動作なので、文字通りの機械語が生成されるとは限らない。
結果的な動作が仕様に反しなければどのような機械語を生成しても言語仕様に準拠していると言って良い。
しかし、逆に言えば最適化で変形したとしても結果は変わらないようになることが保証される。

2025/06/19(木) 21:05:34.31

>>375
最適化では結果は変わらない。
つまり、ちゃんと10で割って、ちゃんと10を掛ける。
10を掛ける方は、マシン語の乗算命令は使われず、
もっと速い命令に置き換えられることが有るが、結果は同じ。

2025/06/19(木) 21:11:49.89

処理系は抽象機械の動作を正確にエミュレートする必要はなく、観測可能な動作のみをエミュレートすればよい。
https://timsong-cpp.github.io/cppwp/n3337/intro.execution#1
だから観測されない動作は削除してもよいというか、削除されることはある。
たとえばその計算結果が全く使われないような状況とか。

ベンチマークしようとして結果を使わない計算をループで囲んだりしてるようなコードではまるごとごそっと消えるなんてのはたまに見る。

2025/06/19(木) 21:16:20.06

セキュリティの問題で普通にゼロクリアした場合でも最適化で削られたりとか昔は問題になったけど…
知らないといけないことは多岐にわたる

2025/06/19(木) 22:14:21.23

>>375
それだと取り除けるケースがあるので保証はされない

2025/06/19(木) 23:09:11.10

>>381
いや、そんなことない。
最適化では結果は変わらない事が保証される。

2025/06/19(木) 23:15:31.49

>>375
あるわけないでしょ
そういう仕様なんだから

2025/06/19(木) 23:25:09.71

意味があるにも関わらず意味がないと判断されると削られる
その場合の対処法もあるので学ばないとまあ残念なことになってしまうと言う話

2025/06/19(木) 23:29:59.97

>>384
いや、今回の割って掛ける場合、そういう事は起きない。

2025/06/19(木) 23:34:50.70

ここの部分はそうだけど
コンパイラの最適化が必ず元の動作を保証してるようなことを書いてるような人がいるから必ずしもそうではないよと

2025/06/19(木) 23:37:52.48

>>386
仕様に明確に書いてあることの動作は変わらない。

2025/06/20(金) 01:42:50.79

>>382
そら結果は同じよ
結果が違っちゃまずいだろうよw
演算をやらない可能性があるってこと

2025/06/20(金) 01:44:00.77

質問じゃ曖昧だけど副作用完了点が間にない場合の話なら、な

2025/06/20(金) 01:58:37.52

>>388
どういうこと？
演算しないと結果は出ないのに、演算せずにどうやって結果だすの？

2025/06/20(金) 08:38:29.48

実行するプログラムではなくてコンパイラが計算までしてしまう
たとえば、printf("%d",12345/10*10); というコードはコンパイルすると、puts("12340"); に変更される可能性がある
出力結果だけは同じだけど、そのコードは大きく変更されてしまう

2025/06/20(金) 09:01:01.71

>>390
変数が関わらない定数だけの演算なら、コンパイルの時点で計算しても結果同じだよね
だから実行時ではなくコンパイルの時点で演算した結果を使う
初歩の最適化の一つ

元の式については左辺に変数が入ってくるから多分最適化はされない
a=b/10*10みたいなのを想定してると思うけど、この場合は最終的に
a=b/10
c=a*10と分解して計算されるので、どちらにも変数が関わってしまい最適化対象外だと思う
a=b*(10/10)みたいな、計算優先度的に変数が関わらないところができれば最適化される

この手の手動最適化なんて考えなくなって久しいから間違ってたらすまぬ

2025/06/20(金) 09:03:31.40

変数があっても結果が同じ計算式で置き換えられるならそうしてくる
10倍よりも8倍+2倍のほうが速い、とかで

2025/06/20(金) 10:35:00.76

最適化のロジックを作るのはまだプログラマーでしょうから。
値を10倍してから10で割るというプログラムを
何もしないに変更するのありかな。
でもわざと桁あふれをさせたい場合もある？！

2025/06/20(金) 10:40:47.81

昔は最適化でバグ混入させられることもあって、最適化は切れってされてたなぁ、っていうおっちゃんのつぶやき

**デフォルトの名無しさん** · 2025/06/20(金) 10:45:39.27

>>392
ここまでの話で「定数だけの演算なら」と何で言い出すのか理解できないけど
>>375では「整数型の変数を」と言っているわけだし
まあそれはおいておいても「コンパイルの時点で計算しても」←演算してんじゃんって俺は思うわけ

>>393
それ自体は問題なくね？
157　を　10で割って15
これに10を掛けるのでなく15*8+15+2 でも最適化の影響はないだろ？
割り算の方でそれが起きるなら問題だけど、>>378の人の話では起きないようだけど

2025/06/20(金) 11:14:53.80

>>396
これ観たら発狂するんじゃね
https://qiita.com/HexagramNM/items/6ca6900b8df37a9b59b8
https://qiita.com/manjuu_eater/items/2e9e38eb001e4b90145b
https://qiita.com/hiramax/items/add36c4fe38900f7175d

2025/06/20(金) 11:57:23.05

>>396
コンパイラで演算しても結果が変わらない場合に限り、コンパイラで演算を行いその結果だけを使う
392でも書いてるが、例題の変数を10で割って10を掛ける動作は演算結果が変わってしまうので最適化は行わない

2025/06/20(金) 12:39:35.73

定数はいつ計算しても同じ結果なんだから最適化されるよ

2025/06/20(金) 12:50:40.34

-O3だとプログラムが動かなくなるから使っていいのは -O2までって先輩に言われてた

2025/06/20(金) 12:53:23.61

何故最適化レベルをワザワザ選べるようにしているのか？
完璧なら選ぶ必要はない
理想論には興味ないから語りたいなら具体的な問題点を上げていけ

2025/06/20(金) 13:06:46.75

>>400
それは言われてたのは知ってるが
「-O3だとプログラムが動かなくなる」のは未定義踏んでるからじゃないか

2025/06/20(金) 13:28:04.40

モバイルc消えてるんだけどなんで？

2025/06/20(金) 13:42:00.01

>>403
あれ便利やった
なんで消されたんやろ

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/20(金) 17:27:19.07

std::formatの件だが、Visual Studio 2022のコンパイラ設定が
デフォルトでC++14標準になってた。すまん。

**デフォルトの名無しさん** · 2025/06/20(金) 18:21:03.44

>>398
そんなことは知ってるのさ
「実行ごとに演算結果が変わる（可能性がある）」から最適化されない、と言うのは良いんだけど
最初からその前提の話をしていたはずなのに「演算をやらない可能性がある」と言い出しただろ？

375 整数型の変数を～（略）～この計算が最適化とかで除かれない保証ってあるの
381 それだと取り除けるケースがあるので保証はされない
382　いや、そんなことない。最適化では結果は変わらない事が保証される。
388　（略）～演算をやらない可能性があるってこと

この流れじゃ『整数型の変数（実行時に結果が変わる）の場合でも最適化によって「演算をやらない可能性がある」』ってニュアンスになっているって気づかんの？
それに対してのどういう状況だ？という>>390だよ
まあ言いたいことは分かったから別にいいけどさ

2025/06/20(金) 19:12:09.11

>>406
回答者にも正しいことを言っている人と間違っていることを言っている人が
いるというだけ。
正しいのは、仕様に明示されている動作については、
最適化してもしなくても結果が変わらないという事だ。
なぜなら、それが仕様なのだから。

2025/06/20(金) 19:41:18.21

>>407
大元の質問からすると仕様が動作を保証するか結果を保証するかをわかってないようだからその説明では不十分でしょ。

2025/06/20(金) 20:44:54.01

保証されます。

2025/06/20(金) 21:00:28.00

コンパイル時に値が決まるようなら実行時に演算されない
そうでない場合でもある整数が決まった値になることが保証されていることがコンパイル時に分かっているなら最適化されて演算されないケースがある
それ以外なら最適化されない

2025/06/20(金) 21:06:32.84

いずれにせよ結果を使わないなら最適化で丸々消される

2025/06/20(金) 21:12:56.63

>>409
ただしバグがなければ

2025/06/20(金) 21:18:29.51

最適化の時点でコードが消されるので直に0で除算をするとコンパイルエラー

変数に突っ込んでるとコンパイル可能で実行してもその部分は最適化され消されてるのでゼロ除算にならない
もちろんconstにしててもコンパイルエラー

2025/06/20(金) 21:43:49.77

>>412
それは、ユーザープログラムのバグではなく、コンパイラのバグだ。
コンパイラにバグが無ければ、四則演算や&,|,~,^,&&,||などと
括弧の組み合わせた結果は、最適化しても変わらない。
0除算に関しては話が別。

2025/06/20(金) 21:48:47.56

最適化されて変わる可能性があるのは、今思い出せるのは、
・初期化してない変数の中身
・変数のアドレス
・結果を利用せず、副作用も伴わない式の存在。
整数に対する四則演算を含めた「計算」は、仕様が決められているので、
同じコンパイラと同じターゲット(OS、環境)だと最適化しても
結果は変わらない。
浮動小数点に対する計算は誤差の範囲で結果が変化する可能性はある。

2025/06/20(金) 22:25:10.37

>>415
1. 整数の計算途中に「桁あふれ」が起きる場合はこの限りではないかも知れない。
　例えば、整数型 a に対して、a * 100 / 5 は、a * 20 と最適化できる
　可能性がある。しかし a がとても大きい場合には結果は同じにはならない可能性がある。このことに
　関して仕様がどうなっているかは知らない。
2. 浮動小数点型の変数 a に対して、(a * 100.0) / 5.0 は、
　a * 20.0 と最適化できる可能性があるが、浮動小数点型には計算誤差があるので、
　誤差の範囲内で異なる結果になる可能性があるかもしれない。
　これに対して仕様上、最適化していいかどうか走らない。
3. しかし、整数型

2025/06/20(金) 22:25:52.67

>>416
3. しかし、整数型変数 a に対して、(a / 100) * 100 は、
　明らかに

2025/06/20(金) 22:26:34.77

>>416
3. しかし、整数型変数 a に対して、(a / 100) * 100 は、
　明らかに a とは、結果が異なる。だから a と最適化される事は無い。

2025/06/21(土) 01:51:51.86

キミは色々と勘違いをしているからこの手の話をしたいならもうちょい勉強しよう
aが何だろうがa*100/5をa*20とはそもそも出来ないし、2.も同様
3.もaの値によっては演算の前後で値がおなじケースがある
色々あるのでいちいち書かなかったが、例えばaが10の倍数の時、aの絶対値が9以下の時、またaが列挙型だったり配列の添字だったりする時は挙動が推測出来るケースも出てくる
他にも最適化で実行時の演算をしなくてすむケースがある
演算をしなくてもaの値を変えることは出来うるし、その場合除算の代わりにいくつかの分岐や直値に変わるだろう

**デフォルトの名無しさん** (JP 0H46-E6Ax) · 2025/06/21(土) 02:46:24.26

また空気読めない書き込みする。ずっと議論
が続いているけど興味ない。

そもそも実数データを表現するbit数が有限
なんだけど(doubleで8byte=64bit)、そりゃあ
場合によっては結果が違うが、実数の場合は
それほど問題じゃない。誤差の範囲内。

整数演算の方が問題。
i=32767/10000*10000の演算やったらどう
なるか？これはコンパイラの最適化の問題
じゃなくてプログラムする人が気をつける
べきことだと思う。というか、変な最適化
はしない方がいいと思う。最適化しなくても
現在のコンピュータ能力じゃあ大して時間差
は問題にならん。

それよりも行列演算でNRVOを実装してほしい。
gccの一部では実装されているみたいだけど。