Приоритет операторов

http://en.cppreference.com/w/c/language/operator_precedence

Если count НЕ равен 10, то будет ли дальше проверяться условия?

Нет (см.).

Или надо так?

Это эквивалентная запись.

P.S. Это к приоритетам прямого отношения не имеет, ленивое вычисление логических выражений это отдельная фича.

Со включенной оптимизацией компилятор (gcc) скорее всего не будет проверять условие дальше, если count != 10.

Спасибо.

Меня терзали сомнения из-за скобок после - count == 10 &&

скорее всего

Не слишком обнадеживающее утверждение)))

Он и без оптимизаций не будет, стандарт требует (вычислить спекулятивно компилятор, конечно, может что угодно, но только если там нету побочных эффектов).

Последний раз проверял несколько лет назад. Тогда GCC не догадывался вычислить оба выражения по сторонам от «&&», чтобы выбросить одно ветвление. Замена на одинарный «&» делала код чуточку быстрее. Это в Си, так что там не было перегрузок.

Что мешает if(count == 10) {бла бла}

Что мешает if(count == 10) {бла бла}

Не зная почему в примере я написал «==», на самом деле так:

if(count < 10 && (strstr(buff, «бла-бла») != NULL || ...

Тогда GCC не догадывался вычислить оба выражения по сторонам от «&&»

Он и не должен этого делать, иначе это компилятор какого-то другого языка, не Си.

Как уже выше написали, в соответствии со стандартом Си, вычисление логического выражения заканчивается, когда результат становится известным. Например, если в (a() && b()) a() возвратила 0, то независимо от того, что возвратит b(), результат будет 0, поэтому b() вызвана не будет.

Он и не должен этого делать

Он может это делать, если всё будет выглядеть так, как будто он этого не делал.

P.S. Это к приоритетам прямого отношения не имеет

Ну тут бабушка надвое сказала, вот запись ТСа «a==10 && ...» и "(a==10) && ..." она теоретически о приоритетах, но как правило о житейской перестраховки и нежелания вникать в язык. :(

но как правило о житейской перестраховки и нежелания вникать в язык.

Ну или для повышения читабельности. Запись со скобками очевидна прям с секундного взгляда, даже задумываться не надо. Я всегда сторонник того, что читаемость кода - это одна из важнейших вещей. Чем меньше ты читаешь доку, чем меньше ты читаешь коменты, чем меньше спрашиваешь коллег, чем меньше строк на которых при чтение ты останавливаешься дольше чем на секунду - тем лучше.

И в добавок у gcc расширения — атрибут чистоты функции. Можно пометить функцию «чистой», не генерирующей побочных эффектов.

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

Очень субъективно. Мне, например, наоборот хуже, когда лишние скобки стоят.

А ещё запись if ((c == 10) || (c == 11)) опаснее, чем if (c == 10 || c == 11). По крайней мере, для GCC. Если вместо двойного равно поставить одинарное, в первом варианте компилятор не будет ругаться. Скобки вокруг присваивания подавляют предупреждение о присваивании в условиях.

без включённой тоже не будет если первый операнд false.

Да без разницы, первое условие отдельным if, если уж сомневаешься.

This. А ещё: не увенен? Поставь скобки! Компелятору всё равно, а человеку читать проще.

У тебя в обоих случаях ничего не выйдет, ибо ты продолбался с закрывающимися скобками ))

Запись со скобками очевидна прям с секундного взгляда

Для тех, кто в свободное время пишет на Лиспе.