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

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

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

2020/06/27(土) 20:57:46.41

あ、ごめん。ないかな？でも作れなくはないか。

2020/06/27(土) 21:01:20.32

>>353
代入文の言語とか

2020/06/27(土) 21:01:54.32

文は値を持たないから

2020/06/27(土) 21:16:43.71

代入式なら
a = b = 0:
は大丈夫だけど、
代入文の言語ではダメ(文法エラー)
卑近な例だと excelVBAとか

2020/06/27(土) 21:48:32.85

>>352
BASIC

2020/06/27(土) 21:54:01.50

あ、そうだ。昔の BASIC がそれだったな。今もそうか。

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

Fortranも駄目だった気がする

2020/06/27(土) 22:45:34.92

iZ-Cで頑張っている方々もいる。

2020/06/27(土) 22:52:26.39

>>359
C言語以前の言語はたいてい駄目だな
例外はLispぐらいかな

2020/06/27(土) 23:11:39.40

ま、しかし、本当なら代入は全く違う記号(あるいはワード)使って欲しいところではある。
昔々中学生の頃に初めてBASICのリストを見て A = A + 1 ってなんじゃこりゃと思った事あるし。
普通の数学や算数とルールが違っているのに同じであるかのような記号の使い回しで混乱w

2020/06/27(土) 23:17:49.21

それ小学生のとき見たからすんなり入ってきた
方程式とは違うよってご丁寧に書いてあったし混乱はなかった

2020/06/27(土) 23:24:19.62

>a = b = 0:
BASICじゃ
bが0なら a=-1
bが0でないなら a=0
だっけ。

2020/06/27(土) 23:37:39.31

そっか、そのとき b = 0 は代入文じゃなくて、値を持つ比較式ですね
文法は間違いでした

2020/06/27(土) 23:38:09.75

文法エラーは間違いでした
でした

2020/06/28(日) 00:32:47.05

=は代入が比較より使用頻度が高いので、2文字(=:)が代入だと地味に面倒そう。

2020/06/28(日) 07:11:45.70

>>362
APLお勧め

2020/06/28(日) 11:47:20.61

iZ-Cに反応しないのは素人か。

2020/06/28(日) 17:12:13.76

>>368
今のAPLはつまんなくなったね

2020/06/28(日) 21:51:57.49

変数名を文字列で取得したいんだけどどうしたらいいかな

printfデバッグとかで、 printf("hogehoge=%d\n",hogehoge); ってやるじゃん？
これをちょっとだけ効率よくしたいけど、マクロでどうにかならん？

2020/06/28(日) 21:54:48.80

>>371
マクロ定義のときは識別子に # を付けると識別子を文字列扱いできる。

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ 8f01-c0lz) · 2020/06/28(日) 22:04:34.55

#define POUT(x) printf("%s = %d\n", #x, (x))
こんな感じ？

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd5f-Oc0l) · 2020/06/28(日) 22:18:47.05

#define POUT(x) printf(#x " = %d\n", (x))
こっちの方がいいか？

2020/06/28(日) 22:53:44.96

文字列リテラルの連結は滅多に使わないけど盲点というか
わかってて使うには良いものだね
"aaaa" "bbbb" → "aaaabbbb" として解釈される

2020/06/28(日) 22:57:59.33

>>375
よく使ってました
長い文字列を記述する際に
空白文字ではなく改行文字を入れてたな

2020/06/28(日) 23:05:22.34

usage表示したいときとか普通に使うわ

2020/06/29(月) 00:09:50.35

私も普通に使う

2020/06/29(月) 01:27:56.70

viがバグるのでやめてください。

2020/06/29(月) 08:55:46.03

vimはバグらないぞ

**デフォルトの名無しさん** (JP 0H43-R4wo) · 2020/06/29(月) 08:57:31.19

もしかして: vim

2020/06/29(月) 08:58:42.61

vimじゃないviには長年世話になったもんだ