C言語なら俺に聞け 155

2020/05/10(日) 23:20:27.99

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

※前スレ
C言語なら俺に聞け 154
https://mevius.5ch.net/test/read.cgi/tech/1578997950/

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

**252** (ﾜｯﾁｮｲ 0f7b-Yzg9) · 2020/06/25(木) 17:22:50.60

いかん、カーニハンさんに「さん」付けるの忘れた。
カーニハンに「さん」を付けるとなんか座りが悪い気がするんだよ。
べつに「ハン」は関西弁の「～はん」じゃないのだけど。

2020/06/25(木) 17:28:33.47

アカデミックな文章のなかでは敬称略はデフォやん

2020/06/25(木) 17:53:32.70

インブリードチェックとかねー
掘り掘りの打ち切り確認とか
可変配列で返せると効率的なのに記述や関数使用方法がCでは面倒くさいという
web上のサラブレッド血統表のインブリードどこも結構いい加減な自動抽出だし

2020/06/25(木) 17:55:14.95

飴ちゃんみたい、蟹はん。

**252** (ﾜｯﾁｮｲ 0f7b-Yzg9) · 2020/06/25(木) 17:58:50.94

>>254
そこは俺の投稿はアカデミックじゃなくて井戸端の噂話くらいなモンってことで。
何なら便所の壁に描かれた傘差したネズミの落書きでもいいのだが。

2020/06/25(木) 21:13:44.78

>>252
正しく実装ってのが何を指してるのかよく分からないけど、その解説ってどこかにある？

2020/06/25(木) 23:23:06.88

2ch (5ch) ではカーニハンは蟹飯とか呼ばれたりするのも普通だからなー。
さんを付けた方がすわりが良いと思うなら付けてもいいが、
ここでは雑に言っても文句は出ないよ。

敬称を付けなきゃ敬意がないってわけでもないし。

2020/06/25(木) 23:35:03.55

蟹めしとしか読めない。

**252** (ﾜｯﾁｮｲ 0f7b-Yzg9) · 2020/06/26(金) 07:00:11.04

>>258 の人に質問されたのでちょこっと書庫をひっくり返してみた。
書籍資料しか示せないし、古い本だから見つけるのは大変かも知れんけど。
今回は「さん」無しで書かせてもらう。人名が多くてやかましくなるでな。

カーニハンによる言及は『プログラミング作法』(ASCII)の第2章。
見直して気づいたけどベントリーからの直接の引用ではなかった。
あと、この本はカーニハンとパイクの共著だったので訂正させてもらう。

ベントリーによる2分探索法は『プログラム設計の着想』(近代科学社)の第4章。
ここに「ベル研とIBMで試したら2時間かけて正しく書けたのは10%」と出てる。
この章をまるまる使って、二分探索ルーチンを題材に、正しいプログラムを書く
手順を説明してるが、使用言語は擬似コードとBASICの方言。

補足としてネット情報 Wikipedia 「二分探索」ページ
特に「実装上の間違い」の部分が興味深いかと。

2020/06/26(金) 07:30:17.89

>>261
丁寧にありがとう。
確かにやらかしてたわw

2020/06/26(金) 07:30:54.43

見てみたけど...

アルゴリズムの問題じゃなくて
ただのインデックスのオーバーフローか

インデックスが計算途中でオーバーフローする心配をするなら
要素数自体がintの範囲を越える心配やメモリ不足の心配もしないと

2020/06/26(金) 07:33:24.14

intじゃ足りないかもしれないから
size_tじゃないとバグとか言い出すのか
くだらん

2020/06/26(金) 07:37:26.08

斜辺を求めるコードも
sqrt(a*a+b*b)
なんて書いたらバグだと言われちゃうね

2020/06/26(金) 07:53:21.24

まあ、ビット数の少ないCPUを使ってた頃はオーバーフローで実際にバグの挙動を示していたこともあったのかもね。
64bitになって、今しばらくはインデックスの足し算をいい加減な順番で行ってもオーバーフローになるほど実メモリが積めなそうだけども。

2020/06/26(金) 08:08:32.76

>>265
aとbがintなのにキャストしないタコいたら許さん

2020/06/26(金) 08:22:33.07

>>263
だからアルゴリズムじゃなくて実装の問題だって話なんだろ。
そして型が int だとか size_t だとかの問題でもない。
どんな型であろうと計算の途中でその型をオーバーフローする可能性がある式だというのが問題であり、扱ってるデータではオーバーフローしないことを意識した上でそういう式を選んでるのかたまたまそういう条件になってるのかは大違いってこと。
最近は64bitだからいちいちそんなこと考える必要もないというなら、それは違うだろと(検索対象がメモリで64bitに及ばないメモリ量の環境でしか使わないコードだという考慮くらいは必要)。
特にライブラリなんかでは、インデックスの許容範囲がその型の許容範囲より狭いならば明記しなければならない。

2020/06/26(金) 08:51:08.83

>>268
>>265もバグという主張だね？

>>267
a, b はdoubleとする

2020/06/26(金) 08:55:01.02

単純な数値計算も簡単じゃなくなるね
大変だ

>>268
底辺a, 高さbの三角形の面積を返す関数を書いてみて

2020/06/26(金) 09:27:28.43

>>269
扱う値の範囲をなんの考慮もせずに書いたコードがたまたま動いてるならバグと言うかはともかく考慮漏れだわな。
巨大な空間で距離を計算する話だったら、とりあえず式が double で足りるかくらい考えるだろ？

>>270
オーバーフロー回避を意識する必要があるなら a / 2 * b とか？
整数型なら a / 2 * b + a & 1 かな？
扱う値によって型なり式なりを選べってことだよ。

2020/06/26(金) 09:39:45.10

>>271
a & 1 にカッコ忘れてるのは多目に見て

2020/06/26(金) 10:09:23.28

>>271
三角形の整数の計算式は全然ダメね。
書き直す気も無いけど、値の範囲に適用する式と型の考慮が必要ってのが言いたいことね。

2020/06/26(金) 10:12:30.36

ビットand の & の優先順位が低いのがすげー気になるマン

2020/06/26(金) 10:24:55.68

>>271
aが小さいとダメだからバグです

2020/06/26(金) 11:51:33.67

確かに、掛け算並みに優先度高くても良い気がする

2020/06/26(金) 12:06:06.43

比較より低いのは仕様バグだな

2020/06/26(金) 12:54:54.87

a,bがdoubleでsqrt(a*a+b*b)以外にどう書けと

2020/06/26(金) 13:34:59.23

>>278
もし double でも計算途中でオーバーフローする可能性があるなら、最初に適当な係数の平方で a b を割って計算してから係数を掛けるとか？
あるいは long double が使えるなら単純にそれで計算するとか。
逆に言えば、オーバーフローする可能性があるならなんとかしないといけないわけだから、なんの変形もせずオーバーフローするに任せたらそれこそバグでしょうよ。

2020/06/26(金) 13:41:41.84

>>279
また嘘言った
後で a b 共に2乗するんだから係数の平方じゃなくて係数そのもので割るんだね。
すまん

2020/06/26(金) 14:27:07.38

doubleでオーバーフローって、10の何乗を想定してる？

2020/06/26(金) 15:19:41.24

aとbの差が大きいときでしょ

2020/06/26(金) 15:43:00.88

それオーバーフローじゃないし、
情報落ちのことだとすればsqrt(a*a+b*b)をどう工夫して防げと？

2020/06/26(金) 16:10:21.31

>>281
1.79769e+308
まさか、これを知らねえんじゃねえよな

2020/06/26(金) 16:42:15.29

で、宇宙の観測可能な距離をヨクトメートル単位で表したら？

2020/06/26(金) 16:44:50.44

デカルト距離は物理的な空間でしか使われないわけじゃないしなあ(屁理屈

2020/06/26(金) 17:02:33.96

64bitあれば大きいほうはエクサ、小さい方はアトまで扱える
今飲んでるコーヒーの液面からカップの底までが１アトパーセクくらい

2020/06/26(金) 17:41:45.88

>>282
aに対してbがはるかに小さいとして
sqrt(a*a+b*b)がaになってもあまり困らない

2020/06/26(金) 17:47:26.42

double で何やったらオーバーフローするのかってことじゃなく、必要な対象を計算するのに必要な型や計算手順は何かってことだろ。
掛け算や指数を扱うならオーバーフローについては普通に考慮するもんだと思うけど、そうじゃないのか？
今扱おうとしてる対象について考慮してるから double なら大丈夫だと考えてるんだろ。
で二分木については足し算がオーバーフローする可能性が盲点ってことで、なるほどと思うべき所だろ。
アルゴリズム上も計算途中に最初に与えた imax を超える値が現れるようには見えないんだから。
今時 double も 64bit整数も当たり前だったとしても、SIMD使いたいからデータ長を抑えたいなんてこともあるでしょ。

2020/06/26(金) 17:54:06.22

一般論で答えても叩かれる
質問内容に特化して答えても叩かれる
どうしろと

2020/06/26(金) 17:56:45.81

俺くらいになればケッセルランを12パーセクで飛ぶくらい余裕

2020/06/26(金) 19:11:05.35

>>289
通常使わない範囲の心配を無条件で(コストをかけてでも)するべき
なんて主張はあほ

その例が>>265

2020/06/26(金) 19:13:45.24

>>278
いくらでも方法がある
ldexp / frexp を使うのが普通かな

2020/06/26(金) 21:15:32.77

>>240
みんなかどうかは知らんがおれは書けるな

2020/06/26(金) 21:18:13.75

>>253
カニチャーハン

2020/06/26(金) 21:39:07.24

int x=0;
int y=(x=1)+(x=2);
とするとyが4になってしまいます。
3だと思うのですが。

◆QZaw55cn4c (NZ 0Hbf-W2Vx) · 2020/06/26(金) 21:43:56.84

>>271
＞オーバーフロー回避を意識する必要があるなら a / 2 * b とか？
それは回避したことになりません、演算子 / 2 と * b のどちらが先に処理されるかはコンパイラが籤引きで決めるか独断偏見で決め打ちするのでは？

◆QZaw55cn4c (NZ 0Hbf-W2Vx) · 2020/06/26(金) 21:46:49.80

>>296
https://ideone.com/w2FJBE
……
そんなことがあるんだ…

2020/06/26(金) 21:52:32.85

逆にして(x=2)+(x=1)
だと 2 だね
https://ideone.com/MbXZtz

2020/06/26(金) 21:54:17.86

>>296
副作用は副作用完了点までのどこかで起こることになっているのでそういうこともある。
っていうか普通は警告が出るでしょ。

2020/06/26(金) 21:57:33.08

int x=0;
x=1;
x=2;
int y=x+x; //(2+2)
という話になっているのだと思われ

2020/06/26(金) 22:03:10.60

あとは優しいおじい・・紳士様がアセンブラでは実際どうなっているかを解説してくれるはず

2020/06/26(金) 22:32:16.04

>>297
自信を持っては言えないけど、/ 2 してから * b するのとその逆とでは結果が違うんだから、書いた式と結果が異なる可能性がある計算順にコンパイラがいじるものかね？
例えば各項を関数として a() / c() * b() にした場合、a ～ c がどの順で実行されるか、つまり項の評価順は保証されないけどそれら結果を使った計算順は式通りになるんじゃないの？

でももし仮にそういう懸念があるなら、カッコ付けるなりそれでだめなら2手に分けるなりすればいいんじゃね。

2020/06/26(金) 22:48:16.05

>>302
アセンブラだとxに2入れて、yに4入れて、おしまいだろうな。

2020/06/26(金) 23:31:20.43

誰も逆汗しないのな。
一昔前だったら
A「俺がやってみるから待ってろ。」
B「いや、俺がやるから(ry」
C「いやいや、俺こそが」
AB「「どうぞどうぞ」」
の前振りだったのに。

VC++2019のデバッグモード
int y = (x = 1) + (x = 2);
00C118FF mov dword ptr [x],1
00C11906 mov dword ptr [x],2
00C1190D mov eax,dword ptr [x]
00C11910 add eax,dword ptr [x]
00C11913 mov dword ptr [y],eax

最適化したら 304 になるんだろうけど。

2020/06/26(金) 23:34:17.38

クソ冗長なコードだな

2020/06/27(土) 00:56:28.31

>>297
/ と * の優先順位は等しくて左結合なんだから疑問の余地はない。
a/2*b と書いてあったら a を 2 で割ってからそれに b をかける。
またはそうしたかのように見えるような振舞いをすることは保証される。
そうなってなかったらコンパイラのバグだよ。

2020/06/27(土) 01:04:32.76

「回避手段があるならバグとしない。」

2020/06/27(土) 01:14:50.37

例えばスケーリングなんかの時、オーバーフローを避けるため割り算やってから掛け算することもあるし、丸め誤差を小さくするため掛け算やってから割り算することもあるし、
意図して式書いてるんだから順序を勝手に変えられたらやっぱり大問題だよな。

2020/06/27(土) 07:08:40.12

>>297
オーバーフローは回避出来てるが
かわりにアンダーフローの可能性が出てくる
だから>>271はバグ

2020/06/27(土) 07:18:53.17

QZがここまでアホだとは

>>296
https://www.jpcert.or.jp/sc-rules/c-exp30-c.html

◆QZaw55cn4c (NZ 0Hbf-W2Vx) · 2020/06/27(土) 07:46:43.88

>>311
ありがとうございます、たしかに副作用完了点に対する私の誤解です
①値の評価の問題、と、②副作用の問題、とを完全にごった煮にしてました、今回は副作用は関係ない…

＞QZがここまでアホだとは
現在までの推移を客観的に観察している限りにおいて、これはスランプでは済まず、私はこれからもっと阿呆になっていくのだろうと私は予測しています
https://mevius.5ch.net/test/read.cgi/tech/1434079972/　へのエントリー数もパッタリ止まってもう増えそうもありません

2020/06/27(土) 08:38:40.98

>>296
鼻から悪魔ネタはもうお腹いっぱい

2020/06/27(土) 08:39:33.42

>>309
行を分けて書けばいいだけ

2020/06/27(土) 08:42:53.25

アホが使うと使い手とそっくりな動きになる
Cとはそういうものだ

2020/06/27(土) 08:45:36.41

>>314
行を分けると何が解決するって？
お前もQZと同じアホ？

2020/06/27(土) 08:48:05.70

>>309
>>268によると
オーバーフローも丸め誤差増大も
両方回避しないとバグらしいぞ

2020/06/27(土) 08:51:31.93

オーバーフローを最近勉強して
それだけが気になって
それを回避するために別の問題を起こす
初心者君のたわごとだから
放置すればいいんだけど

2020/06/27(土) 08:57:09.10

どんくらいまでの誤差を許容すべきかは
なかなか数学的な考えどころ

2020/06/27(土) 09:11:00.12

許容誤差
パラメーターの対応範囲
コスト
保守性、可読性、...

これらを総合的に考えてコードを作るのが普通
1個だけの要素が気になるといびつな実装になる

色々な規格も偏った視野で作られる事が多くて
いびつな物が多い

それぞれの項目を勉強するのはもちろん良いこと

2020/06/27(土) 09:23:41.94

>>317
両方起こりえる状況なら変数の精度不足というバグか。

2020/06/27(土) 09:32:46.13

>>316
ああアホには「文」を分けると書かないとわからんかw

2020/06/27(土) 09:40:26.98

文を分けると何が解決するって？

乗算と除算の演算順がコンパイラによって変わる
というのはQZの勘違いな主張で
明確に順番は決まってる
(QZが>>312で勘違いを認めている)

2020/06/27(土) 09:50:13.95

オーバーフローの話は (imax + imin) / 2 ではなく imin + (imax - imin) 2 と書けば回避できるってのが発端なわけだけど、何がそんなに気にくわないんだ？
盲点とも言えるよくやりがちなことなんだから、素直に吸収しときゃいいんじゃないの？

2020/06/27(土) 10:02:32.81

>>324
オーバーフローの可能性があるならそうやって回避可能
っていうだけの話なのに

パラメーターの型全ての値に対応出来ないとバグ
とか言い出す人がいるから

2020/06/27(土) 10:08:05.06

>>325
それってどれのこと？

2020/06/27(土) 10:11:14.54

あぁ、もしかして >>268 のことか？
んじゃ int の代わりに size_t だったら >>324 の前者の式のままでもいいってのがお前の主張か。

2020/06/27(土) 10:20:58.17

元はカーニハンとかいう人だろ
その影響を受けたのが>>268

オーバーフローの可能性が無いなら
前者のままでも良いっていうか
前者の方が良い場合もある

コストは確実に前者の方が安い
リニア検索ではなくてコードサイズの大きな2分検索を使うあたり
パフォーマンスが全くどうでも良い所ではないということもわかるわけで

移植性は後者、コストは前者、
可読性は微妙だが前者？

intよりsize_tを使うべきなんて思ってないよ
使う範囲、使う環境、移植性、...
などなどでどうするべきかは変わる

2020/06/27(土) 10:23:22.01

>>328
お前が揶揄してる人(おれ)が言ってることがようするに
> 使う範囲、使う環境、移植性、...
を考慮して選択しろと言ってるんだが。

2020/06/27(土) 10:23:42.01

C言語スレだから

チープな8bit環境から
スーパーコンピューターまで
様々な所で使われる

重視すべき項目は時と場合で大きく違う

2020/06/27(土) 10:25:33.79

>>327を見ると
常に後者を選ぶべき
だと思ってるように見えるけど

2020/06/27(土) 10:29:38.97

>>268 の次の >>271 なんかを含め流れを見て言ってくれてるのかしら

2020/06/27(土) 10:49:08.20

>>265 も
オーバーフローやアンダーフローを意識してコーティングすべきと

それは良い心がけで

2020/06/27(土) 11:08:27.27

>>333
たぶん論旨は伝わったと思うので追い打ちかけるつもりではないが、レス付けるに当たっては「オーバーフローを回避するなら」と必ず付けてるし、扱う値の範囲を鑑みて型が充分か考慮しろと言ってるだけのことな。
扱うのが宇宙の座標をメートル単位で、くらいの話なら double でもオーバーフロー的な問題は無いなとか、
でももしシミュレーションで宇宙を100次元空間として体積を求める話だったら double でも大丈夫かな？とか考慮するでしょ。
まあそんなケースだと値の大きさより有効桁の方が心配だけど、なんにしてもとりあえずデカい型だから大丈夫wなんて漫然と思ってるならただのアホという至極当然の話。

2020/06/27(土) 12:40:30.36

>>323
> 乗算と除算の演算順がコンパイラによって変わる
> というのはQZの勘違いな主張で
> 明確に順番は決まってる
エビデンス持って来てからほざけ

2020/06/27(土) 12:53:15.33

>>334
状況によって適切なコードを選ぶべきと思ってるなら別にいい
そうじゃなさそうだったので

｢間違ってる｣｢バグ｣｢正しくない｣という主張じゃなかった？

2分検索が10%しか正しく書けないなんてことはないと思うんだがね

2020/06/27(土) 13:02:32.88

>>336
>2分検索が10%しか正しく書けないなんてことはないと思うんだがね
そう、ここが気になったんだけど、でももし二分検索を書いたこと無い人がアルゴリズムを見て一発で動作するコードが書けるか？という話なら、案外その程度かもと思ったり。
分割時の端数処理の考慮が不適切でインデックスが変化せず無限ループに陥ったり、検索から抜け落ちる要素が出たり、要素数が0～2ないし3くらいの範囲でうまく動かなかったり。
ちょっと動かせばすぐ修正点に気付いて動くコードに仕立てられるだろうけど、ぶっつけで動かせるかと言ったら案外難しいんじゃね。

2020/06/27(土) 14:22:51.51

クイックソートを一発で書けと言われるとちょっとつらい。
あまりにうろ覚えすぎる。

30分待ってやる
と言われれば思い出しながら余裕を持って書ける。かな？

いやどうだろう？
ソートは完璧だろうけど、アルゴリズムはあやしいな
「クイックに似た何かソート」になりそうかも

◆QZaw55cn4c (ﾜｯﾁｮｲ ffe9-W2Vx) · 2020/06/27(土) 15:37:58.80

>>296,298-301
些細なことですが、>>296,298,299 の結果は納得いかないです

＞int y = (x = 1) + (x = 2);

たしかに gcc/clang とも警告は出ますが、しかしそれはシーケンスポイント間で i を複数回書き込んでいる、という警告で、それは i の値が 2, 5 のいずれかになるか不確定という意味ですね

しかし演算子 + のオペランドの値は確定していて、すなわち 2 と 5
だから y の値は、この場合は確定的に 7 になるはずです

実際、手元の clang(8,0,1) でコンパイルした場合、結果は y = 7 で上の解釈と合致します。
私は gcc がバグっていると思いました。

◆QZaw55cn4c (ﾜｯﾁｮｲ ffe9-W2Vx) · 2020/06/27(土) 15:40:36.38

>>339
×シーケンスポイント間で i を複数回書き込んでいる、という警告で、それは i の値が 2, 5 のいずれかになるか不確定
○シーケンスポイント間で x を複数回書き込んでいる、という警告で、それは x の値が 2, 5 のいずれかになるか不確定

2020/06/27(土) 16:04:40.17

既出かもしれんが
＞int y = (x = 1) + (x = 2);
演算順は
(x = 1)
(x = 2)
左辺値 x + 左辺値 x
y = その結果
なんじゃないの？

◆QZaw55cn4c (ﾜｯﾁｮｲ ffe9-W2Vx) · 2020/06/27(土) 16:14:25.88

>>339
なんだか >>340 だけではなくて、いろいろ間違えまくってますね…ごめんなさい、今日は寝ます

◆QZaw55cn4c (ﾜｯﾁｮｲ ffe9-W2Vx) · 2020/06/27(土) 16:26:01.60

>>341　ありがとうございます
JISX0301 の代入演算子をみると
＞「6.5.16 セマンティクス「代入式は、代入後の左オペランドの値を持つが、左辺値でない」
つまり
式 x = 2
の値は 2 ではなく x というわけですか…なるほど

2020/06/27(土) 18:53:06.85

式の値は x = 1 なら 1 だけど、その式の値が x と同一といわれると微妙な気が
コンパイラによって結果が変わってきそうな気も

2020/06/27(土) 19:00:52.23

数学の変数とプログラムの変数は別物。

2020/06/27(土) 20:34:42.19

そもそもイコールではなくて代入だもんね

2020/06/27(土) 20:36:44.26

比較が =
代入が :=
の方が良かったと思う

2020/06/27(土) 20:37:36.35

2020/06/27(土) 20:39:21.93

>>342
寝るの早いよ！

2020/06/27(土) 20:42:32.55

つぴゅう太BASIC

2020/06/27(土) 20:44:48.50

>>347
PASCALが嫌いな人が作った言語でか？

2020/06/27(土) 20:56:58.25

代入も比較も同じ = 記号なんだけど代入した結果を利用できない言語はあるね。