回答。

問題の歴史：

論理演算子 && と || は、C言語で複雑な論理条件をチェックするために導入されました。これらの動作の特徴は、ショートサーキット評価をサポートしていることです：結果が最初のオペランドで明確に決定できる場合、2番目のオペランドは評価されません。

問題：

多くのプログラマーは、両方のオペランドが常に評価されることを期待したり、2番目のオペランドで副作用を誤って使用したりします。これにより、リソースの漏洩や予期しない動作が発生します。

解決策：

ショートサーキット評価の仕組みを理解することで、特にポインタ、リソース、ファイルのチェックにおいて、安全な構造を構築する助けになります。右側の式での副作用の使用は、意識的である場合にのみ許可されます。安全なチェックの例：

if (ptr && ptr->field) { /* ... */ }

主な特徴：

• && と || はショートサーキットの原則を使用しており、最初のオペランドの後に結果が未定義の場合にのみ2番目のオペランドが評価されます。
• ショートサーキットにより、ヌルポインタへのアクセスやゼロ除算など、危険な状況を回避できます。
• 副作用を持つ式のネスト時にエラーが発生し、右側がまったく実行されない可能性があります。

トラップのある質問。

フラグメント：if (0 && f()) の場合、f() は実行されますか？

いいえ、f() 関数は呼び出されません。なぜなら、結果はすでに明らかだからです — 式は偽であり、さらなる評価は無駄です。

次の記述では：if (1 || f()) はどうですか？

再び f() は呼び出されません：結果は最初のオペランドの後にすでに真です。

副作用を持つ関数の実行順序を制御するために && と || 演算子を使用できますか？

技術的には可能ですが、そのような制御は読みづらく、不安定なコードにつながります。副作用のためにショートサーキット動作に依存せず、関数の呼び出しの順序を明示的に記述するのが良いでしょう。

一般的なエラーとアンチパターン

• 副作用を持つ右側の式を期待して使用すること。
• ポインタの逆参照前に NULL チェックを怠ること。
• 評価順序の理解を妨げる複雑なネスト条件。

実生活からの例

ネガティブケース

if (flag || process()) {
    // ...
}

フラグが真の場合、プロセスは決して呼び出されません。

利点:

• 不要な作業からの保護があります。

欠点:

• 期待されていたときに副作用が発生せず、バグが発生します。

ポジティブケース

if (!flag) process();

利点:

• 読みやすく、安全で予測可能なコードです。

欠点:

• いくつかの行が増え、より明確な制御が必要ですが、読みやすさと予測可能性が向上します。