Ответ.

История вопроса:

Логические операторы && и || введены в C для проверки сложных логических условий. Особенность их работы — поддержка вычисления по короткому замыканию: второй операнд не вычисляется, если результат можно однозначно определить уже по первому.

Проблема:

Многие программисты ожидают, что оба операнда всегда вычисляются, или неверно используют побочные эффекты во втором операнде, предполагая, что он обязательно выполнится. На практике это приводит к ошибкам, утечкам ресурсов и неожиданному поведению.

Решение:

Понимание механизма short-circuit evaluation помогает строить безопасные конструкции, особенно в проверках указателей, ресурсов и файлов. Использование side-effects в правой части выражения допустимо только осознанно. Пример безопасной проверки:

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

Ключевые особенности:

• && и || используют правило 'короткого замыкания' — второй операнд вычисляется только если результат не определен после первого.
• Короткое замыкание позволяет избежать обращения к нулевым указателям, делению на ноль и другим опасным ситуациям.
• Ошибки возникают при вложении выражений с побочными эффектами, когда правая часть может не выполниться вовсе.

Вопросы с подвохом.

Будет ли выполнено выражение f() во фрагменте: if (0 && f())

Нет, функция f() не вызовется, потому что результат уже ясен — выражение ложно, дальнейшее вычисление бесполезно.

А в следующей записи: if (1 || f())?

Снова f() не вызовется: результат уже истинен после первого операнда.

Можно ли использовать операторы && и || для управления порядком выполнения функций с побочными эффектами?

Технически можно, но такое управление ведет к нечитаемому и нестабильному коду. Лучше явно расписывать порядок вызова функций, не полагаясь на short-circuit behavior для side-effects.

Типовые ошибки и анти-паттерны

• Использование побочных эффектов в правой части выражений в надежде, что они обязательно отработают.
• Отсутствие проверки на NULL перед разыменованием указателя.
• Сложные вложенные условия, мешающие пониманию порядка вычисления.

Пример из жизни

Негативный кейс

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

Процесс никогда не вызовется, если flag истинно.

Плюсы:

• Есть защита от ненужной работы.

Минусы:

• Побочные эффекты не происходят, когда ожидались, возникает баг.

Позитивный кейс

if (!flag) process();

Плюсы:

• Читаемый, безопасный и предсказуемый код.

Минусы:

• Немного больше строк, требует более явного контроля, но читаемость и предсказуемость возрастают.