アカウント名:
パスワード:
if((...) && (uid = 0)){}これを 0 == uid 以外だめってことにすればいいんじゃない?というか eq とか subst とかいうマクロにしたらどうだい?
本家には wait4: 'if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) ...' と書いてますね。なんで日本語だと本文に無いんだか。
で、これだと代入が括弧で囲まれてるから警告出ないと。確かにcurrent.uid == 0だと括弧要らないですが、&&の右辺だと括弧入れるコーディングスタイルの人も多いから厄介ですね。それもあって単なるうっかりミスかもしれないとも言われてました（ちゃんと議論追ってないので良く分からないですが）。
この場合だと二重括弧じゃないと警告出すようにすれば良いとも思うのですが、しかし色々と一貫性を考えてみるとそもそもCの構文が悪い気もする。
> 色々と一貫性を考えてみるとそもそもCの構文が悪い気もする。
つまり、「=」が代入で「==」が比較というCの定義が悪いということだと思います。あるいは、代入を構文ではなく演算子だとしてしまったために、式が書けるあらゆるところで代入が可能になってしまったのが悪いということでしょうか。
たしかに、Cの基本設計（代入は演算子なので、本来、ifの条件式の中でも代入ができるべき）を認めた上で、かつ今回のような問題を防ぐには、小手先の小細工になってしまうし、一貫性を失って奇妙なことになる（カッコで囲まれていたら警告を出さないとか）と思います。
だったら、Cでその定義は今更変えられないから、新しい言語を作って、BASICみたいに「=」は演算子じゃないことにしてしまうか、FORTRANみたいに比較は「eq」とかを使うようにするか、Pascalみたいに代入は「:=」で比較は「=」にするか、でも、C式の定義がC以外にも広く使われてるし、かえって混乱を招くかもしれません。
代入が式であることが問題で、記号はどうでもいいでしょう。あとは条件式がbool以外を取れることが問題です。言語仕様を変えなくても、コンパイラがそれをチェックして警告を出すことは可能だと思いますよ。
しかし、この場合、条件の値が0なので、もしそんな警告が存在すれば、NULLやFALSEを0と定義している場合、全て警告を出されてしまうので、到底実用的じゃないと思う。
言ってるように、括弧が付こうがなんだろうが、代入を式として評価しない方がいいし、それで十分だろう。
括弧付き代入の警告も、既存のプログラムだと警告が結構でるかもしれないと思ったので、その点はあえて目をつぶりました。警告はOFFにできるしね。
Cじゃない別の言語を作る話なら、bool以外取らないという解決策の方が個人的には良いと思う。代入式がそこら中に書けるのはシンプルで分かりやすいコードにできる方法だと思う。代入1つのために中抜けループとか作りたくないし。
> Cじゃない別の言語を作る話なら、bool以外取らないという解決策の方が個人的には良いと思う。
if ((count < MAX) || (f = true)) {のようにbool型の変数へ代入してしまうバグは残る（作れる）ので万全とはいいにくい気が
# さらにboolの比較演算子をなくせばいいかな？# if (!is_not_support() != false) みたいなコードもなくなるし
> 代入1つのために中抜けループとか作りたくないし。
while (c = getchar() ; c != EOF) {…}のようにかければ、ほかは「代入文」でもなんとかなりません？
個人的には「代入文」（もしくは代入演算子の戻りをvoid）にして整理したほうが学習コストもバグ発生率も下げられるのでは？と思ってます
#2476303 ですが、私が考えてたのは、代入が式として扱えることには何ら異論はなくて、exp1 && exp2は正当なのに、if exp hogeと書けないのが変だなということでした。
&&のような条件演算子だって短絡評価を使えば実際if文に近い使い方はできるのに、左右に表れる式に括弧をつけなくても問題ない。ただし、自主的に括弧をつける人も多い。一方、if文だと式に必ず括弧をつける必要がある。で、代入文を括弧で囲わないと式として扱わない（警告を出す）ようにした場合、if文だとコード上は二重の括弧で囲われた形になるのに対し
&&のあとだとどうだとか、二重括弧がどうだとか、こんなにややこしいことを考えないといけないのなら、いっそのこと、代入を式として扱えることを放棄してしまったほうが単純明快なのではと思います。
ひとつで複数の副作用を起こせる文（あるいは式）が存在する、ということそのものが、人間のすなおな理解を超えているんじゃないかと思うのです。（べつに、人間の理解力を超えていると言いたいわけじゃないです。疲れてるときとか、うっかりとか、そういうときにミスが出やすいポイントだと思います）。というわけで私は #2476486の意見に賛成です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
C が悪い(フレームのもと) (スコア:0, 興味深い)
if((...) && (uid = 0)){}
これを 0 == uid 以外だめってことにすればいいんじゃない?
というか eq とか subst とかいうマクロにしたらどうだい?
Re: (スコア:1)
本家には wait4: 'if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) ...' と書いてますね。なんで日本語だと本文に無いんだか。
で、これだと代入が括弧で囲まれてるから警告出ないと。確かにcurrent.uid == 0だと括弧要らないですが、&&の右辺だと括弧入れるコーディングスタイルの人も多いから厄介ですね。それもあって単なるうっかりミスかもしれないとも言われてました（ちゃんと議論追ってないので良く分からないですが）。
この場合だと二重括弧じゃないと警告出すようにすれば良いとも思うのですが、しかし色々と一貫性を考えてみるとそもそもCの構文が悪い気もする。
Re: (スコア:0)
> 色々と一貫性を考えてみるとそもそもCの構文が悪い気もする。
つまり、「=」が代入で「==」が比較というCの定義が悪いということだと思います。
あるいは、代入を構文ではなく演算子だとしてしまったために、式が書けるあらゆる
ところで代入が可能になってしまったのが悪いということでしょうか。
たしかに、Cの基本設計（代入は演算子なので、本来、ifの条件式の中でも代入が
できるべき）を認めた上で、かつ今回のような問題を防ぐには、小手先の小細工になって
しまうし、一貫性を失って奇妙なことになる（カッコで囲まれていたら警告を出さないとか）
と思います。
だったら、Cでその定義は今更変えられないから、新しい言語を作って、
BASICみたいに「=」は演算子じゃないことにしてしまうか、
FORTRANみたいに比較は「eq」とかを使うようにするか、
Pascalみたいに代入は「:=」で比較は「=」にするか、
でも、C式の定義がC以外にも広く使われてるし、かえって混乱を招くかもしれません。
Re: (スコア:0)
代入が式であることが問題で、記号はどうでもいいでしょう。
あとは条件式がbool以外を取れることが問題です。
言語仕様を変えなくても、コンパイラがそれをチェックして警告を出すことは可能だと思いますよ。
Re: (スコア:0)
しかし、この場合、条件の値が0なので、もしそんな警告が存在すれば、NULLやFALSEを0と定義している場合、全て警告を出されてしまうので、到底実用的じゃないと思う。
言ってるように、括弧が付こうがなんだろうが、代入を式として評価しない方がいいし、それで十分だろう。
Re: (スコア:0)
括弧付き代入の警告も、既存のプログラムだと警告が結構でるかもしれないと思ったので、
その点はあえて目をつぶりました。警告はOFFにできるしね。
Cじゃない別の言語を作る話なら、bool以外取らないという解決策の方が個人的には良いと思う。
代入式がそこら中に書けるのはシンプルで分かりやすいコードにできる方法だと思う。
代入1つのために中抜けループとか作りたくないし。
Re: (スコア:0)
> Cじゃない別の言語を作る話なら、bool以外取らないという解決策の方が個人的には良いと思う。
if ((count < MAX) || (f = true)) {
のようにbool型の変数へ代入してしまうバグは残る（作れる）ので万全とはいいにくい気が
# さらにboolの比較演算子をなくせばいいかな？
# if (!is_not_support() != false) みたいなコードもなくなるし
> 代入1つのために中抜けループとか作りたくないし。
while (c = getchar() ; c != EOF) {…}
のようにかければ、ほかは「代入文」でもなんとかなりません？
個人的には「代入文」（もしくは代入演算子の戻りをvoid）にして整理したほうが学習コストもバグ発生率も下げられるのでは？と思ってます
Re: (スコア:0)
#2476303 ですが、私が考えてたのは、代入が式として扱えることには何ら異論はなくて、
exp1 && exp2は正当なのに、if exp hogeと書けないのが変だなということでした。
&&のような条件演算子だって短絡評価を使えば実際if文に近い使い方はできるのに、左右に表れる式に括弧をつけなくても問題ない。ただし、自主的に括弧をつける人も多い。
一方、if文だと式に必ず括弧をつける必要がある。
で、代入文を括弧で囲わないと式として扱わない（警告を出す）ようにした場合、if文だとコード上は二重の括弧で囲われた形になるのに対し
Re:C が悪い(フレームのもと) (スコア:0)
&&のあとだとどうだとか、二重括弧がどうだとか、
こんなにややこしいことを考えないといけないのなら、
いっそのこと、代入を式として扱えることを放棄してしまったほうが単純明快なのではと思います。
ひとつで複数の副作用を起こせる文（あるいは式）が存在する、ということそのものが、
人間のすなおな理解を超えているんじゃないかと思うのです。
（べつに、人間の理解力を超えていると言いたいわけじゃないです。
疲れてるときとか、うっかりとか、そういうときにミスが出やすいポイントだと思います）。
というわけで私は #2476486の意見に賛成です。