[c/c++] логические операции. Они ленивые?

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

ISO/IEC 9899:TC3

The && operator shall yield 1 if both of its operands compare unequal to 0; otherwise, it yields 0. The result has type int. Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares equal to 0, the second operand is not evaluated.

> Если firstBoolFunc() возвращает true, будет ли выполняться secondBoolFunc()?

будет. т.к. && - должны оба быть тру. если firstBoolFunc() - false - то вторая выполняться не будет.

ну и для логического или тоже самое. т.е. для ||. с поправкой на условия (до первого тру, остальное не выполняется).

Да, тут где-то были товарищи, заявляющие, что мол это не гарантированно и зависит от компилятора (хотя еще в K&R написано про выполнение слева направо при прекращении, если вычисление следующего выражения не требуется для вычисления общего результата), что они натыкались на эти грабли. Один сказал, что в bcb 2009 есть параметр full boolean evalution, с которым выражения вычисляются всегда. Мало того, что его еще надо включить, при том, что такое поведение противоречит всем принятым соглашениям и стандартам, так я еще и не нашел его в указанной IDE... Так что делаю вывод, что товарищ тот врал, пытаясь выкрутиться из своего невежества.

>&=

Это побитовая операция, да еще и с присваиванием. Приведите пример.

>Если firstBoolFunc() возвращает true, будет ли выполняться secondBoolFunc()?

Конечно будет, у тебя же операнд «&&» два оператора должны быть true чтобы логическое условие выдало true. Этот операнд просто не может быть «ленивым». А вот «||» уже будет ленивым.

P.S. Смени же ты уже аватарку, глаза мозолит это безобразие.

> будет. т.к. && - должны оба быть тру. если firstBoolFunc() - false - то вторая выполняться не будет.

Это опечатка, имело в виду ||

>>&=

Это побитовая операция, да еще и с присваиванием. Приведите пример.

Да, она тут ни к чему, как и &&

зависит от компилятора (хотя еще в K&R написано

Керниган и Ричи не могут гарантировать, что кто-то не напишет компилятор с другой семантикой. Хотя кто стал бы его использовать - но это другой вопрос.

Компилятор с другой семантикой, нарушающей стандарты, не является компилятором языка C. Можете его называть компилятором языка Borland C.

Можете его называть компилятором языка Borland C.

Ну этот как только не называли :)

>>зависит от компилятора (хотя еще в K&R написано

Керниган и Ричи не могут гарантировать, что кто-то не напишет компилятор с другой семантикой.

Это будет чем угодно, но не компилятором языка Си. Как выше и написали =)

там в стандарте дофига мест «на усмотрение реализаторов». при переносе с венды обязательно что-нибудь ломается потихоньку..

В принципе тут,

[code=cpp] if (firstBoolFunc() || secondBoolFunc()) { } [/code]

если firstBoolFunc() == true, то дальше secondBoolFunc() вычисляться не должна и результат операции || будет true.

Тут,

[code=cpp] if (firstBoolFunc() && secondBoolFunc()) { } [/code]

если firstBoolFunc() == false, то дальше secondBoolFunc() вычисляться не должна и результат операции || будет false.

Как то так.

ЗЫ: Чем спрашивать - мог бы проверить в дебаггере или printf - ов натыкать и посмотреть как оно будет. :)

ЗЫЗЫ: херня ваш LORCODE

>>операции || будет false.

операции && будет false.

use code=c, luke

Кстати, даже если вычисления ленивые, то не факт, что сначала вычислится firstBoolFunc(), а не secondBoolFunc(). Короче, чтобы всё было гарантированно, придётся городить такой быдлокод:

if (firstBoolFunc())
    func();
else if (secondBoolFunc())
    func();

проверить в дебаггере или printf - ов натыкать

Здравствуйте, Григорий Остер :)

> не факт, что сначала вычислится firstBoolFunc(), а не secondBoolFunc(). Короче, чтобы всё было гарантированно

Как раз это никому не нужно

> Один сказал, что в bcb 2009 есть параметр full boolean evalution, с которым выражения вычисляются всегда.

Он, наверно, с дельфёй попутал. Там точно такая настройка есть.

> Он, наверно, с дельфёй попутал. Там точно такая настройка есть.

Там это еще с Паскаля тянется.

Obey-Kun, скажи мне сколько книг по С/C++ ты прочитал от корки до корки?

От корки до корки белую библию.

Выборочно Шилдта (первые главы целиком) и Джосаттиса.

Мне хватает. Идиотские вопросы иногда возникают, но в остальном проблем нет.

#include <stdbool.h>
...
bool a = firstBoolFunc(), b = secondBoolFunc();
if (a || b) {
    // ...
}

K&R же...

> От корки до корки белую библию.

Что это?

Это как раз хороший код. А быдлокод - это сайдэффекты в логических операциях и условиях. Собственно, один из самых распространенных примеров быдлокода.

Кстати, даже если вычисления ленивые, то не факт, что сначала вычислится firstBoolFunc(), а не secondBoolFunc().

Утчи матчасть, школота непоротая, Стандрт Си гарантирует вычисление логических выражений слева направо.

> Что это?

K&R

вот и выросло поколение, не знающее про белую книгу.

Так бы сразу и сказали, что K&R. Но судя по вашим вопросам от корки до корки вы ее точно не прочитали.

> вот и выросло поколение, не знающее про белую книгу.

Никогда не слышал про белую книгу, для нормальных людей эта книга идентифицируется тремя символами: K&R

Это было давно. Моя профессия не связана с программированием (я геолог) и после некоторого времени некоторые знания отошли на задний план, увы.

Так и занимайтесь геологией, чего в программирование то лезете?

а как же мифы и предания? черная книга? книга дракона? книга, которая не лезет ни на одну полку?

без этого скучно как-то, не?

> вот и выросло поколение, не знающее про белую книгу.

Вот и выросло поколение у которого после прочтения K&R в голове пусто.

PS: а топикстартеру судя по его постам надо Страуструпа читать, а не K&R

А вот книгу дракона я знаю

лень читать весь тред, для C - да,
для C++ - зависит от того перегружен operator || и operator && или нет.
в случае перегруженного ничего сказать нельзя - может выполнится, а может и нет, причем даже порядок выполнения нельзя заранее сказать.

> топикстартеру судя по его постам надо Страуструпа читать, а не K&R

так за советами он и пришел, не?

Потому, что нехрен в условиях сравнения не константные методы вызывать. И нечего по граблям бегать.

>книга, которая не лезет ни на одну полку?
а это про которую?

В C++ зависит от того, каким образом были перегружены операторы || и &&. Если они были именно перегружены, то, ребятки, будут выполняться обе функции…

Глядя на фрагмент кода, сказать ничего нельзя, нет?

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

Правильно, потому что перегруженный оператор превращается в вызов операторной функции.

> Если они были именно перегружены, то, ребятки, будут выполняться обе функции…

Так то оно так, только на практике перегружать эти операторы не стоит.

вроде про прикладную криптографию шнаера. она у меня совершенно точно нифига не помещается на полке.

Если firstBoolFunc() возвращает true, будет ли выполняться secondBoolFunc()?

Если у вас нет глобальных переменных и функций с side-effect, это фиолетово. Если есть - надо не порядок вычисления изучать, а нормальный код начинать писать :-)

> у тебя же операнд «&&» два оператора должны быть true чтобы логическое условие выдало true. Этот операнд просто не может быть «ленивым». А вот «||» уже будет ленивым.

4.2, && является ленивым, когда первый операнд - false (второй вычислять не нужно,т.к.выражение уже false).

>Так то оно так, только на практике перегружать эти операторы не стоит.

будь моя воля - я бы вообще запретил перегружать операторы, ибо от этого одна головная боль.

&& || , ?: это все для чего определен порядок а в С++ первых три операции грех перегружать так что и в нем можно полагатся на порядок

лень читать весь тред, для C - да,

Согласно тем же K&R - не для всех архитектур, где-нибудь аргументы могут и справа налево рассматриваться.

Процитируешь? А то некий Ритчи утверждает, что еще в языке B все было слева направо.