1

language: C

a bool expression outputs 0 if 0 is entered, else 1 will be the output.

following the above statement,

CASE 1:

input

#include <stdio.h>
#include <stdbool.h>
main()
{
    int a = 1,
        b = 2;
    bool res = ((a == b) && ("your "));
    printf("res = %d", res);
}

output

res = 0

CASE 2:

input

    bool res = (!(a == b) && ("your "));
    printf("res = %d", res);

output

res = 1

CASE 3: now i add prinf function to ("your ")

input

    bool res = ((a == b) && printf("your "));
    printf("res = %d", res);

output

res = 0 //adding printf doesn't change the output

CASE 4: input

    bool res = (!(a == b) && printf("your "));
    printf("res = %d", res);

output

your res = 1 // i expected just "res = 1" not "your res = 1"

how is the print function not executed in CASE 3 but executed in CASE 4?

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
  • duplicate: [Why do logical operators in C not evaluate the entire expression when it's not necessary to?](https://stackoverflow.com/q/39613707/995714) – phuclv Jan 11 '21 at 16:52

3 Answers3

2

According to the C Standard (6.5.13 Logical AND operator)

4 Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation; if the second operand is evaluated, there is a sequence point between the evaluations of the first and second operands. If the first operand compares equal to 0, the second operand is not evaluated.

In the expression used as an initializer in this declaration

bool res = ((a == b) && printf("your "));

the first operand (a == b) of the logical AND operator evaluates to 0. So the second operand that is the call of printf is not evaluated,

On the other hand, in this expression used as an initializer in the declaration

bool res = (!(a == b) && printf("your "));
 

the first operand !(a == b) evaluates to 1. So the second operand that is the call of printf is also evaluated.

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
  • does it short circuit in every case or does it halt in some cases? or what if i use scanf(which has to be declared) instead of printf(already declarred).. – neversettle evolve Jan 11 '21 at 17:38
  • @neversettleevolve It is a general behavior of the logical AND operator. scanf has the return type int. So it may be used in an expression with the logical AND operator. – Vlad from Moscow Jan 11 '21 at 17:40
1

The evaluation of logical and operator && is short-circuit evaluation.

Considering A && B, firstly A is evaluated. When A is true, A && B can become true and B is evaluated. When A is false, A && B will never be true and B is not evaluated.

Now look at actual cases.

In CASE 3 (a == b) && printf("your "), (a == b) is false because a (1) is not equal to b (2). Therefore now we lost all chance for the expression (a == b) && printf("your ") to become true and therefore printf("your ") is not evaluated. This means the function is not executed.

In CASE 4 !(a == b) && printf("your "), !(a == b) is true because (a == b) is false. Now the expression !(a == b) && printf("your ") may become true depending on the value of printf("your "), so printf("your ") is evaluated and the function is executed.

MikeCAT
  • 73,922
  • 11
  • 45
  • 70
-2

In Case 3:

It is due to compiler optimizing the statement. The statement is translated and evaluated from left to right because of the usage of parentheses. The first expression is: (a == b) is false because of the values of a and b. The compiler figured out that the result of the expression in ((a == b) && printf("your")) will always yield false. So optimization dictates not to generate code for printf("your"). I bet if you compile this in demode mode, you will see the expected result.

Explanation of case 4 is left for yourself. It is obvious. (hint pay attention to the precedence of the operators "!", "&&")

Good luck.

Blaise
  • 11
  • 2
  • 1
    no it's absolutely not related to optimization. It's purely due to short-circuit evaluation – phuclv Jan 11 '21 at 16:40
  • optimization **must not** change the observable behavior. Only in C++ a few constructors can be optimized out, but this question is about C – phuclv Jan 11 '21 at 16:47
  • And it has nothing to do with the parentheses in this code. – Eric Postpischil Jan 11 '21 at 17:16
  • Wouldn't a short circuit evaluation be part of optimization scheme? It is obvious that parentheses may not have anything to do with the behavior, but nonetheless they make the codes easier to understand. – Blaise Jan 12 '21 at 22:28
  • Can you kindly explain and contrast the differences in cases 4 and 3 in terms clear for the guy to understand. As far as I am concerned, your points did not seem to bring any bright light to the questions asked by the guy. – Blaise Jan 12 '21 at 22:37