RFC 1122 によれば Robustness principle とは "Be liberal in what you accept, and conservative in what you send" です。
日本語に訳しますと「送る側は慎重に、受け取る側は寛大に」
この場合sendされるはソースコードでacceptするのは SmileBASICです。その出力が実行結果。
工夫が必要な、ともすれば綱渡りのようなコードをsendするよりもSmileBASICの意図どおりに && || を使うのがより Robustness principle にかなっていませんか?
and or * + を「かつ」「または」の意味で使うのはRFCで言えばMAY相当でしょう。
&& || を使うことがSHOULD相当ですね。無論MUSTではない。
とりゅふさん、置き去りにしてごめんね。
うえこうさん、孤立無援四面楚歌絶体絶命の中救援ありがとう。
実は && || には and or よりも平均的に速いという特性もあるんですよ。
この仕様は C 言語からの借用なんですけど、そもそも C 言語は筋金入りのハッカーが自分達が使うために設計して実装した言語なんで、とびきり使いやすくできてるんです。
数値の&と論理積の&&の意味がわかってる人だったらどっちでもいいんじゃないかな。
困るのは
IF (BUTTON(2) AND 16) AND FLAG==0 THEN
で動きませんと言われた時ですね。
それなら「&&を使いましょう」と言いたくなるかも。16と1をANDしても0ですが、16と1の&&なら成立するんですよというのをうまく説明できません。
あきとさんへ
「&&」を勧めるのがベターですが、個人的には「(BUTTON(2) AND 16)」に比較演算子を加えて「(BUTTON(2) AND 16)==16」とします。
「0以外の値だとtrueになる」「『BUTTON(2) AND 16』は0か16のいずれかの値になる」というのが分からない状態で「&&」を勧めても結局正しい理解はできないままになりますので。
>イカさん
おちゃめさんの説明に加えて挙動面の補足です。
・A && B ⇒ AとBが両方とも0でない時は1に、それ以外の時は0にする演算子。また、Aが0の時はBは処理されない(関数なら呼ばれない)
・A AND B ⇒ AとBの、各ビットの論理積の結果を返す演算子(&B1010 AND &B1001==&B1011)
プチコン三号ではこのように動きます。
C言語も全く同じです。(記号は違いますが)
dim v[4] という整数の配列から x という値を探すとして
i = 0
while i < 4 && v%[i] != x
i = i + 1
wend
と書けば期待通りに動くんですけど、これを and にしちゃうとバグるのね。こういういちいちプログラマ好みな仕様が C 言語やめられまへんな～な理由です。
>みき氏は妙齢の素敵な女性だし
違いますね。そういやめぐりー先生には「動けばいい」と言ってたれいさんが、Newあっきーさんには方法論を語ってるあたりも、なるほどと思いましたね。
イカさん、
if P then if Q then ～
if P && Q then ～
は完全に一致します。
うえこうさんへ
A=2、かつ、B=4を判定したい場合にA==2 && B==4 と記述するのがベターでA==2 AND B==4 でも問題ないというのが私の考えです。
A=2、かつ、B=4を判定したい場合にA AND B と記述すると明らかに間違いですが、A && B としても正しくはありません。
A && Bが正しく動作するのはAが0もしくは2という値を取り、Bが0もしくは4という値を取るときのみだからです。
したがって、IF文が正しく動作しないという場合はANDを&&に変えれば解決できるという単純なものではなく比較演算子を省略しないのがベストということです。
そして、みき★さんも書かれていますがANDで正常に動作しない場合もあるので比較演算子を省略しない場合でも&&を使うのがベターです。
