C言語なら俺に聞け 155

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん (ﾜｯﾁｮｲ 76ba-P5bm)
垢版 |
2020/05/10(日) 23:20:27.99ID:Z3WQBr9X0
!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(金) 08:22:33.07ID:zNtEkj210
>>263
だからアルゴリズムじゃなくて実装の問題だって話なんだろ。
そして型が int だとか size_t だとかの問題でもない。
どんな型であろうと計算の途中でその型をオーバーフローする可能性がある式だというのが問題であり、扱ってるデータではオーバーフローしないことを意識した上でそういう式を選んでるのかたまたまそういう条件になってるのかは大違いってこと。
最近は64bitだからいちいちそんなこと考える必要もないというなら、それは違うだろと(検索対象がメモリで64bitに及ばないメモリ量の環境でしか使わないコードだという考慮くらいは必要)。
特にライブラリなんかでは、インデックスの許容範囲がその型の許容範囲より狭いならば明記しなければならない。
2020/06/26(金) 08:51:08.83ID:ulI8ykG3d
>>268
>>265もバグという主張だね？

>>267
a, b はdoubleとする
2020/06/26(金) 08:55:01.02ID:ulI8ykG3d
単純な数値計算も簡単じゃなくなるね
大変だ

>>268
底辺a, 高さbの三角形の面積を返す関数を書いてみて
2020/06/26(金) 09:27:28.43ID:zNtEkj210
>>269
扱う値の範囲をなんの考慮もせずに書いたコードがたまたま動いてるならバグと言うかはともかく考慮漏れだわな。
巨大な空間で距離を計算する話だったら、とりあえず式が double で足りるかくらい考えるだろ？

>>270
オーバーフロー回避を意識する必要があるなら a / 2 * b とか？
整数型なら a / 2 * b + a & 1 かな？
扱う値によって型なり式なりを選べってことだよ。
2020/06/26(金) 09:39:45.10ID:zNtEkj210
>>271
a & 1 にカッコ忘れてるのは多目に見て
2020/06/26(金) 10:09:23.28ID:zNtEkj210
>>271
三角形の整数の計算式は全然ダメね。
書き直す気も無いけど、値の範囲に適用する式と型の考慮が必要ってのが言いたいことね。
2020/06/26(金) 10:12:30.36ID:DHczgJjy0
ビットand の & の優先順位が低いのがすげー気になるマン
2020/06/26(金) 10:24:55.68ID:0ez7fC22d
>>271
aが小さいとダメだからバグです
2020/06/26(金) 11:51:33.67ID:CsRb/b6RM
確かに、掛け算並みに優先度高くても良い気がする
2020/06/26(金) 12:06:06.43ID:wPd6FHznd
比較より低いのは仕様バグだな
2020/06/26(金) 12:54:54.87ID:hOK/Kg/V0
a,bがdoubleでsqrt(a*a+b*b)以外にどう書けと
2020/06/26(金) 13:34:59.23ID:zNtEkj210
>>278
もし double でも計算途中でオーバーフローする可能性があるなら、最初に適当な係数の平方で a b を割って計算してから係数を掛けるとか？
あるいは long double が使えるなら単純にそれで計算するとか。
逆に言えば、オーバーフローする可能性があるならなんとかしないといけないわけだから、なんの変形もせずオーバーフローするに任せたらそれこそバグでしょうよ。
2020/06/26(金) 13:41:41.84ID:zNtEkj210
>>279
また嘘言った
後で a b 共に2乗するんだから係数の平方じゃなくて係数そのもので割るんだね。
すまん
2020/06/26(金) 14:27:07.38ID:QICJMmXvM
doubleでオーバーフローって、10の何乗を想定してる？
2020/06/26(金) 15:19:41.24ID:gU0A9MqI0
aとbの差が大きいときでしょ
2020/06/26(金) 15:43:00.88ID:QICJMmXvM
それオーバーフローじゃないし、
情報落ちのことだとすればsqrt(a*a+b*b)をどう工夫して防げと？
2020/06/26(金) 16:10:21.31ID:tBxKhrZw0
>>281
1.79769e+308
まさか、これを知らねえんじゃねえよな
2020/06/26(金) 16:42:15.29ID:QICJMmXvM
で、宇宙の観測可能な距離をヨクトメートル単位で表したら？
2020/06/26(金) 16:44:50.44ID:R6SXx1iE0
デカルト距離は物理的な空間でしか使われないわけじゃないしなあ(屁理屈
2020/06/26(金) 17:02:33.96ID:tBxKhrZw0
64bitあれば大きいほうはエクサ、小さい方はアトまで扱える
今飲んでるコーヒーの液面からカップの底までが１アトパーセクくらい
288デフォルトの名無しさん (ﾜｲｰﾜ2 FFbf-/Fs/)
垢版 |
2020/06/26(金) 17:41:45.88ID:PjbtVFt+F
>>282
aに対してbがはるかに小さいとして
sqrt(a*a+b*b)がaになってもあまり困らない
2020/06/26(金) 17:47:26.42ID:zNtEkj210
double で何やったらオーバーフローするのかってことじゃなく、必要な対象を計算するのに必要な型や計算手順は何かってことだろ。
掛け算や指数を扱うならオーバーフローについては普通に考慮するもんだと思うけど、そうじゃないのか？
今扱おうとしてる対象について考慮してるから double なら大丈夫だと考えてるんだろ。
で二分木については足し算がオーバーフローする可能性が盲点ってことで、なるほどと思うべき所だろ。
アルゴリズム上も計算途中に最初に与えた imax を超える値が現れるようには見えないんだから。
今時 double も 64bit整数も当たり前だったとしても、SIMD使いたいからデータ長を抑えたいなんてこともあるでしょ。
290デフォルトの名無しさん (ﾜｲｰﾜ2 FFbf-/Fs/)
垢版 |
2020/06/26(金) 17:54:06.22ID:PjbtVFt+F
一般論で答えても叩かれる
質問内容に特化して答えても叩かれる
どうしろと
2020/06/26(金) 17:56:45.81ID:9etEQyfpM
俺くらいになればケッセルランを12パーセクで飛ぶくらい余裕
2020/06/26(金) 19:11:05.35ID:EPLAnBEId
>>289
通常使わない範囲の心配を無条件で(コストをかけてでも)するべき
なんて主張はあほ

その例が>>265
2020/06/26(金) 19:13:45.24ID:EPLAnBEId
>>278
いくらでも方法がある
ldexp / frexp を使うのが普通かな
294デフォルトの名無しさん (ｱｳｱｳｳｰ Sad3-u/pE)
垢版 |
2020/06/26(金) 21:15:32.77ID:TyyL07+Ya
>>240
みんなかどうかは知らんがおれは書けるな
295デフォルトの名無しさん (ｱｳｱｳｳｰ Sad3-u/pE)
垢版 |
2020/06/26(金) 21:18:13.75ID:TyyL07+Ya
>>253
カニチャーハン
2020/06/26(金) 21:39:07.24ID:/YkOh9yY0
int x=0;
int y=(x=1)+(x=2);
とするとyが4になってしまいます。
3だと思うのですが。
2020/06/26(金) 21:43:56.84ID:9IxUvn/4H
>>271
＞オーバーフロー回避を意識する必要があるなら a / 2 * b とか？
それは回避したことになりません、演算子 / 2 と * b のどちらが先に処理されるかはコンパイラが籤引きで決めるか独断偏見で決め打ちするのでは？
2020/06/26(金) 21:46:49.80ID:9IxUvn/4H
>>296
https://ideone.com/w2FJBE
……
そんなことがあるんだ…
299デフォルトの名無しさん (ﾜｯﾁｮｲ 8fe6-vKxb)
垢版 |
2020/06/26(金) 21:52:32.85ID:Sd6G194T0
逆にして(x=2)+(x=1)
だと 2 だね
https://ideone.com/MbXZtz
2020/06/26(金) 21:54:17.86ID:gtOtInFM0
>>296
副作用は副作用完了点までのどこかで起こることになっているのでそういうこともある。
っていうか普通は警告が出るでしょ。
301デフォルトの名無しさん (ﾜｯﾁｮｲ 8fe6-vKxb)
垢版 |
2020/06/26(金) 21:57:33.08ID:Sd6G194T0
int x=0;
x=1;
x=2;
int y=x+x; //(2+2)
という話になっているのだと思われ
302デフォルトの名無しさん (ﾜｯﾁｮｲ 8fe6-vKxb)
垢版 |
2020/06/26(金) 22:03:10.60ID:Sd6G194T0
あとは優しいおじい・・紳士様がアセンブラでは実際どうなっているかを解説してくれるはず
2020/06/26(金) 22:32:16.04ID:zNtEkj210
>>297
自信を持っては言えないけど、/ 2 してから * b するのとその逆とでは結果が違うんだから、書いた式と結果が異なる可能性がある計算順にコンパイラがいじるものかね？
例えば各項を関数として a() / c() * b() にした場合、a ～ c がどの順で実行されるか、つまり項の評価順は保証されないけどそれら結果を使った計算順は式通りになるんじゃないの？

でももし仮にそういう懸念があるなら、カッコ付けるなりそれでだめなら2手に分けるなりすればいいんじゃね。
2020/06/26(金) 22:48:16.05ID:GYQIE3peM
>>302
アセンブラだとxに2入れて、yに4入れて、おしまいだろうな。
2020/06/26(金) 23:31:20.43ID:ONx8T6wJ0
誰も逆汗しないのな。
一昔前だったら
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.38ID:GYQIE3peM
クソ冗長なコードだな
2020/06/27(土) 00:56:28.31ID:VCabyp7F0
>>297
/ と * の優先順位は等しくて左結合なんだから疑問の余地はない。
a/2*b と書いてあったら a を 2 で割ってからそれに b をかける。
またはそうしたかのように見えるような振舞いをすることは保証される。
そうなってなかったらコンパイラのバグだよ。
2020/06/27(土) 01:04:32.76ID:zYxBmbbI0
「回避手段があるならバグとしない。」
2020/06/27(土) 01:14:50.37ID:qKnmoagb0
例えばスケーリングなんかの時、オーバーフローを避けるため割り算やってから掛け算することもあるし、丸め誤差を小さくするため掛け算やってから割り算することもあるし、
意図して式書いてるんだから順序を勝手に変えられたらやっぱり大問題だよな。
2020/06/27(土) 07:08:40.12ID:TsX0h7IG0
>>297
オーバーフローは回避出来てるが
かわりにアンダーフローの可能性が出てくる
だから>>271はバグ
2020/06/27(土) 07:18:53.17ID:TsX0h7IG0
QZがここまでアホだとは

>>296
https://www.jpcert.or.jp/sc-rules/c-exp30-c.html
2020/06/27(土) 07:46:43.88ID:5JNhQ0LTH
>>311
ありがとうございます、たしかに副作用完了点に対する私の誤解です
①値の評価の問題、と、②副作用の問題、とを完全にごった煮にしてました、今回は副作用は関係ない…

＞QZがここまでアホだとは
現在までの推移を客観的に観察している限りにおいて、これはスランプでは済まず、私はこれからもっと阿呆になっていくのだろうと私は予測しています
https://mevius.5ch.net/test/read.cgi/tech/1434079972/　へのエントリー数もパッタリ止まってもう増えそうもありません
2020/06/27(土) 08:38:40.98ID:Fil4ka9J0
>>296
鼻から悪魔ネタはもうお腹いっぱい
2020/06/27(土) 08:39:33.42ID:Fil4ka9J0
>>309
行を分けて書けばいいだけ
2020/06/27(土) 08:42:53.25ID:aqzZKmXR0
アホが使うと使い手とそっくりな動きになる
Cとはそういうものだ
2020/06/27(土) 08:45:36.41ID:TsX0h7IG0
>>314
行を分けると何が解決するって？
お前もQZと同じアホ？
2020/06/27(土) 08:48:05.70ID:TsX0h7IG0
>>309
>>268によると
オーバーフローも丸め誤差増大も
両方回避しないとバグらしいぞ
2020/06/27(土) 08:51:31.93ID:TsX0h7IG0
オーバーフローを最近勉強して
それだけが気になって
それを回避するために別の問題を起こす
初心者君のたわごとだから
放置すればいいんだけど
2020/06/27(土) 08:57:09.10ID:aqzZKmXR0
どんくらいまでの誤差を許容すべきかは
なかなか数学的な考えどころ
2020/06/27(土) 09:11:00.12ID:TsX0h7IG0
許容誤差
パラメーターの対応範囲
コスト
保守性、可読性、...

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

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

それぞれの項目を勉強するのはもちろん良いこと
2020/06/27(土) 09:23:41.94ID:6HwwPL420
>>317
両方起こりえる状況なら変数の精度不足というバグか。
2020/06/27(土) 09:32:46.13ID:Fil4ka9J0
>>316
ああアホには「文」を分けると書かないとわからんかw
2020/06/27(土) 09:40:26.98ID:TsX0h7IG0
文を分けると何が解決するって？

乗算と除算の演算順がコンパイラによって変わる
というのはQZの勘違いな主張で
明確に順番は決まってる
(QZが>>312で勘違いを認めている)
2020/06/27(土) 09:50:13.95ID:qKnmoagb0
オーバーフローの話は (imax + imin) / 2 ではなく imin + (imax - imin) 2 と書けば回避できるってのが発端なわけだけど、何がそんなに気にくわないんだ？
盲点とも言えるよくやりがちなことなんだから、素直に吸収しときゃいいんじゃないの？
2020/06/27(土) 10:02:32.81ID:TsX0h7IG0
>>324
オーバーフローの可能性があるならそうやって回避可能
っていうだけの話なのに

パラメーターの型全ての値に対応出来ないとバグ
とか言い出す人がいるから
2020/06/27(土) 10:08:05.06ID:qKnmoagb0
>>325
それってどれのこと？
2020/06/27(土) 10:11:14.54ID:qKnmoagb0
あぁ、もしかして >>268 のことか？
んじゃ int の代わりに size_t だったら >>324 の前者の式のままでもいいってのがお前の主張か。
2020/06/27(土) 10:20:58.17ID:TsX0h7IG0
元はカーニハンとかいう人だろ
その影響を受けたのが>>268

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

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

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

intよりsize_tを使うべきなんて思ってないよ
使う範囲、使う環境、移植性、...
などなどでどうするべきかは変わる
2020/06/27(土) 10:23:22.01ID:qKnmoagb0
>>328
お前が揶揄してる人(おれ)が言ってることがようするに
> 使う範囲、使う環境、移植性、...
を考慮して選択しろと言ってるんだが。
2020/06/27(土) 10:23:42.01ID:TsX0h7IG0
C言語スレだから

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

重視すべき項目は時と場合で大きく違う
2020/06/27(土) 10:25:33.79ID:TsX0h7IG0
>>327を見ると
常に後者を選ぶべき
だと思ってるように見えるけど
2020/06/27(土) 10:29:38.97ID:qKnmoagb0
>>268 の次の >>271 なんかを含め流れを見て言ってくれてるのかしら
2020/06/27(土) 10:49:08.20ID:TsX0h7IG0
>>265 も
オーバーフローやアンダーフローを意識してコーティングすべきと

それは良い心がけで
2020/06/27(土) 11:08:27.27ID:qKnmoagb0
>>333
たぶん論旨は伝わったと思うので追い打ちかけるつもりではないが、レス付けるに当たっては「オーバーフローを回避するなら」と必ず付けてるし、扱う値の範囲を鑑みて型が充分か考慮しろと言ってるだけのことな。
扱うのが宇宙の座標をメートル単位で、くらいの話なら double でもオーバーフロー的な問題は無いなとか、
でももしシミュレーションで宇宙を100次元空間として体積を求める話だったら double でも大丈夫かな？とか考慮するでしょ。
まあそんなケースだと値の大きさより有効桁の方が心配だけど、なんにしてもとりあえずデカい型だから大丈夫wなんて漫然と思ってるならただのアホという至極当然の話。
2020/06/27(土) 12:40:30.36ID:Fil4ka9J0
>>323
> 乗算と除算の演算順がコンパイラによって変わる
> というのはQZの勘違いな主張で
> 明確に順番は決まってる
エビデンス持って来てからほざけ
2020/06/27(土) 12:53:15.33ID:F1FZoULud
>>334
状況によって適切なコードを選ぶべきと思ってるなら別にいい
そうじゃなさそうだったので

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

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

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

いやどうだろう？
ソートは完璧だろうけど、アルゴリズムはあやしいな
「クイックに似た何かソート」になりそうかも
2020/06/27(土) 15:37:58.80ID:vUQmFWhd0
>>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 がバグっていると思いました。
2020/06/27(土) 15:40:36.38ID:vUQmFWhd0
>>339
×シーケンスポイント間で i を複数回書き込んでいる、という警告で、それは i の値が 2, 5 のいずれかになるか不確定
○シーケンスポイント間で x を複数回書き込んでいる、という警告で、それは x の値が 2, 5 のいずれかになるか不確定
2020/06/27(土) 16:04:40.17ID:WNNU6Y/YK
既出かもしれんが
＞int y = (x = 1) + (x = 2);
演算順は
(x = 1)
(x = 2)
左辺値 x + 左辺値 x
y = その結果
なんじゃないの？
2020/06/27(土) 16:14:25.88ID:vUQmFWhd0
>>339
なんだか >>340 だけではなくて、いろいろ間違えまくってますね…ごめんなさい、今日は寝ます
2020/06/27(土) 16:26:01.60ID:vUQmFWhd0
>>341　ありがとうございます
JISX0301 の代入演算子をみると
＞「6.5.16 セマンティクス「代入式は、代入後の左オペランドの値を持つが、左辺値でない」
つまり
式 x = 2
の値は 2 ではなく x というわけですか…なるほど
2020/06/27(土) 18:53:06.85ID:fF6t87uZa
式の値は x = 1 なら 1 だけど、その式の値が x と同一といわれると微妙な気が
コンパイラによって結果が変わってきそうな気も
2020/06/27(土) 19:00:52.23ID:zYxBmbbI0
数学の変数とプログラムの変数は別物。
2020/06/27(土) 20:34:42.19ID:5xR8poHP0
そもそもイコールではなくて代入だもんね
2020/06/27(土) 20:36:44.26ID:TsX0h7IG0
比較が =
代入が :=
の方が良かったと思う
2020/06/27(土) 20:37:36.35ID:5xR8poHP0
:3
2020/06/27(土) 20:39:21.93ID:ItnTp6fM0
>>342
寝るの早いよ！
2020/06/27(土) 20:42:32.55ID:zYxBmbbI0
つ ぴゅう太BASIC
2020/06/27(土) 20:44:48.50ID:aqzZKmXR0
>>347
PASCALが嫌いな人が作った言語でか？
352デフォルトの名無しさん (ﾜｯﾁｮｲ 3fad-p8b5)
垢版 |
2020/06/27(土) 20:56:58.25ID:YxSvZ5UV0
代入も比較も同じ = 記号なんだけど代入した結果を利用できない言語はあるね。
353デフォルトの名無しさん (ﾜｯﾁｮｲ 3fad-p8b5)
垢版 |
2020/06/27(土) 20:57:46.41ID:YxSvZ5UV0
あ、ごめん。ないかな？でも作れなくはないか。
2020/06/27(土) 21:01:20.32ID:fF6t87uZa
>>353
代入文の言語とか
2020/06/27(土) 21:01:54.32ID:fF6t87uZa
文は値を持たないから
2020/06/27(土) 21:16:43.71ID:fF6t87uZa
代入式なら
a = b = 0:
は大丈夫だけど、
代入文の言語ではダメ(文法エラー)
卑近な例だと excelVBAとか
2020/06/27(土) 21:48:32.85ID:TsX0h7IG0
>>352
BASIC
358デフォルトの名無しさん (ﾜｯﾁｮｲ 3fad-p8b5)
垢版 |
2020/06/27(土) 21:54:01.50ID:YxSvZ5UV0
あ、そうだ。昔の BASIC がそれだったな。今もそうか。
2020/06/27(土) 22:14:52.03ID:8IoNpLP20
Fortranも駄目だった気がする
360デフォルトの名無しさん (ﾜｯﾁｮｲ ff8c-ZANo)
垢版 |
2020/06/27(土) 22:45:34.92ID:3uU6UKGu0
iZ-Cで頑張っている方々もいる。
2020/06/27(土) 22:52:26.39ID:Fil4ka9J0
>>359
C言語以前の言語はたいてい駄目だな
例外はLispぐらいかな
362デフォルトの名無しさん (ﾜｯﾁｮｲ 3fad-p8b5)
垢版 |
2020/06/27(土) 23:11:39.40ID:YxSvZ5UV0
ま、しかし、本当なら代入は全く違う記号(あるいはワード)使って欲しいところではある。
昔々中学生の頃に初めてBASICのリストを見て A = A + 1 ってなんじゃこりゃと思った事あるし。
普通の数学や算数とルールが違っているのに同じであるかのような記号の使い回しで混乱w
2020/06/27(土) 23:17:49.21ID:WNNU6Y/YK
それ小学生のとき見たからすんなり入ってきた
方程式とは違うよってご丁寧に書いてあったし混乱はなかった
2020/06/27(土) 23:24:19.62ID:zYxBmbbI0
>a = b = 0:
BASICじゃ
bが0なら a=-1
bが0でないなら a=0
だっけ。
2020/06/27(土) 23:37:39.31ID:fF6t87uZa
そっか、そのとき b = 0 は代入文じゃなくて、値を持つ比較式ですね
文法は間違いでした
2020/06/27(土) 23:38:09.75ID:fF6t87uZa
文法エラーは間違いでした
でした
2020/06/28(日) 00:32:47.05ID:akwdxVh60
=は代入が比較より使用頻度が高いので、2文字(=:)が代入だと地味に面倒そう。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。