order in if(expression)

[Babis Haldas]

i have

if(i==1 && func1() ) do something

if i!=1 , func1 doesnt run at all
this is in my compiler

is this because the compiler or because the stantard
can i rely that in any system func1 will never run if i!=1
(so first agument is checked first)

thanks

[Gavin Deane]

Babis Haldas wrote:

i have

if(i==1 && func1() ) do something

if i!=1 , func1 doesnt run at all
this is in my compiler

is this because the compiler or because the stantard
can i rely that in any system func1 will never run if i!=1
(so first agument is checked first)

That behaviour is standard. You can rely on it. If the left hand side
of && eavluates to false, the right hand side is not evaluated at all.

The logical-or operator || behaves similarly. If the left hand side
evaluates to true, the right hand side is not evaluated.

Gavin Deane

[Ron Lima]

> if(i==1 && func1() ) do something

If you need func1 to run, dispite the value of 1, then this expression
will not work for you, since if i is different from 1, the expression
containing fun1 will not be evaluated.

It is considered poor style relying on the evaluation order of
expressions since it may cause confusion on the reader of your code. It
is a better idea to rewrite your code in a way to get the function
calls outside expressions in order to make it clearer.

[Jaspreet]

Babis Haldas wrote:

i have

if(i==1 && func1() ) do something

if i!=1 , func1 doesnt run at all
this is in my compiler

is this because the compiler or because the stantard
can i rely that in any system func1 will never run if i!=1
(so first agument is checked first)

thanks

&& and || are called shortcut operators. && returns a TRUE only if
the expression on left and right side of the && operator is TRUE. In
your case, if 'i !=1' then there is no point in doing the right hand
side of the expression.

So basically you can rely on the standard and always assume that in
case of && if the first expression is FALSE the right hand side would
not be calculated.

Similarly, in-case of || if the first expression is TRUE the second
expression (on the right side) would not be calculated since || returns
a TRUE even if one of the expressions are TRUE.

[Ben Pope]

Ron Lima wrote:

if(i==1 && func1() ) do something <snip> can i rely that in any
system func1 will never run if i!=1 (so first agument is checked
first)
If you need func1 to run, dispite the value of 1, then this
expression will not work for you, since if i is different from 1, the
expression containing fun1 will not be evaluated.

I've included the bit you snipped, where he says he *does not* want it
to run if i != 1.
It is considered poor style relying on the evaluation order of
expressions since it may cause confusion on the reader of your code.
I think the use of "short-circuit" logical operators is pretty idiomatic
for programmers of many languages.
It is a better idea to rewrite your code in a way to get the function
calls outside expressions in order to make it clearer.

Having function calls outside of expressions is not always possible and
not necessarily clearer.

consider:

int myFunc getVal() {
return 42;
}

int main() {
int myInt = getVal();
}

How do you suggest I remove that function call from the expression?

Actually, in the case of initialisation, that's easy:

int myInt(getVal());

But not for assignment.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Tomás]

Babis Haldas posted:

i have

if(i==1 && func1() ) do something

if i!=1 , func1 doesnt run at all
this is in my compiler

is this because the compiler or because the stantard
can i rely that in any system func1 will never run if i!=1
(so first agument is checked first)

thanks

They call it "short-circuit analysis". The compiler doesn't need to know
what the second one evalutes to, so it doesn't bother.

However, if you need "func1" to be called, then simply chang:

if( i==1 && func1() )
{
; //Code
}

to:

if ( func1() )
{
if ( i == 1 )
{
; //Code
}
}
-Tomás

[Tomás]

Tomás posted:

if( i==1 && func1() )
{
; //Code
}

Also, I forgot to mention. It is undefined whether "i == 1" will be
evaluated first, or if "func1()" will be evaluated first.

-Tomás

[Gavin Deane]

Tomás wrote:

Tomás posted:

if( i==1 && func1() )
{
; //Code
}

Also, I forgot to mention. It is undefined whether "i == 1" will be
evaluated first, or if "func1()" will be evaluated first.

That's not true. In the code above, it is guaranteed that i==1 will be
evaluated first and it is guaranteed that func1() will only be
evaluated in the case that i==1 evaluated to true.

&& introduces a sequence point after the evaluation of the first
expression.

Gavin Deane

[Rolf Magnus]

Tomás wrote:

However, if you need "func1" to be called, then simply chang:

if( i==1 && func1() )
{
; //Code
}

to:

if ( func1() )
{
if ( i == 1 )
{
; //Code
}
}

Or simply:

if (func1() && i == 1)
{
//Code
}

[Jaspreet]

Tomás wrote:

Tomás posted:

if( i==1 && func1() )
{
; //Code
}

Also, I forgot to mention. It is undefined whether "i == 1" will be
evaluated first, or if "func1()" will be evaluated first.

-Tomás

I guess not. It is defined that i==1 would be calculated first and
depending on its result would the compiler work on evaluating / calling
func1().

[Andre Kostur]

"Gavin Deane" <de*********@hotmail.com> wrote in
news:11**********************@i40g2000cwc.googlegr oups.com:

Babis Haldas wrote:

i have

if(i==1 && func1() ) do something

if i!=1 , func1 doesnt run at all
this is in my compiler

is this because the compiler or because the stantard
can i rely that in any system func1 will never run if i!=1
(so first agument is checked first)

That behaviour is standard. You can rely on it. If the left hand side
of && eavluates to false, the right hand side is not evaluated at all.

The logical-or operator || behaves similarly. If the left hand side
evaluates to true, the right hand side is not evaluated.

This all assumes that operator&& (or operator||) has not been overloaded.
If it has, then the if statement becomes a function call, and both sides
will be evaluated, in an indeterminate order.

[Gavin Deane]

Andre Kostur wrote:

"Gavin Deane" <de*********@hotmail.com> wrote in
news:11**********************@i40g2000cwc.googlegr oups.com:

Babis Haldas wrote:

i have

if(i==1 && func1() ) do something

if i!=1 , func1 doesnt run at all
this is in my compiler

That behaviour is standard. You can rely on it. If the left hand side
of && eavluates to false, the right hand side is not evaluated at all.

The logical-or operator || behaves similarly. If the left hand side
evaluates to true, the right hand side is not evaluated.

This all assumes that operator&& (or operator||) has not been overloaded.
If it has, then the if statement becomes a function call, and both sides
will be evaluated, in an indeterminate order.

True. I was assuming the built-in meaning of the operators. The change
in semantics implied sounds to me like a good reason for thinking very
carefully before overloading those operators.

Gavin Deane

[Marcus Kwok]

Gavin Deane <de*********@hotmail.com> wrote:

Andre Kostur wrote:

"Gavin Deane" <de*********@hotmail.com> wrote in
news:11**********************@i40g2000cwc.googlegr oups.com:

> That behaviour is standard. You can rely on it. If the left hand side
> of && eavluates to false, the right hand side is not evaluated at all.
>
> The logical-or operator || behaves similarly. If the left hand side
> evaluates to true, the right hand side is not evaluated.

This all assumes that operator&& (or operator||) has not been overloaded.
If it has, then the if statement becomes a function call, and both sides
will be evaluated, in an indeterminate order.

True. I was assuming the built-in meaning of the operators. The change
in semantics implied sounds to me like a good reason for thinking very
carefully before overloading those operators.

Same thing applies to comma operator: an overloaded operator,() will no
longer generate a sequence point.

--
Marcus Kwok

[Tomás]

Rolf Magnus posted:

Tomás wrote:

However, if you need "func1" to be called, then simply chang:

if( i==1 && func1() )
{
; //Code
}

to:

if ( func1() )
{
if ( i == 1 )
{
; //Code
}
}

Or simply:

if (func1() && i == 1)
{
//Code
}

I'm open to correction, but I'm 90% certain that I read that the order of
evaluation is undefined, and thus that "i == 1" could still be evaluated
before "func1()", even in the example you give.

I think "C++ for Dummies" has an example of this, something like:

extern bool g();
extern bool h();

if ( g() || h() )
{
//We don't know which functions were called
}
-Tomás

[Ben Pope]

Tomás wrote:

I'm open to correction, but I'm 90% certain that I read that the order of
evaluation is undefined, and thus that "i == 1" could still be evaluated
before "func1()", even in the example you give.

I think "C++ for Dummies" has an example of this, something like:

extern bool g();
extern bool h();

if ( g() || h() )
{
//We don't know which functions were called
}

The built in operator && and operator || has a sequence point in it.
This has already been mentioned.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Gavin Deane]

Tomás wrote:

I'm open to correction, but I'm 90% certain that I read that the order of
evaluation is undefined, and thus that "i == 1" could still be evaluated
before "func1()", even in the example you give.
5.14/1

The && operator groups left-to-right.
The operands are both implicitly converted to type bool (clause 4).
The result is true if both operands are true and false otherwise.
Unlike &, && guarantees left-to-right evaluation: the second operand is
not evaluated if the first operand is false.

5.15/1 says similar for ||

1.9/18 states that there is a sequence point after evaluation of the
first expression.
I think "C++ for Dummies" has an example of this, something like:

extern bool g();
extern bool h();

if ( g() || h() )
{
//We don't know which functions were called
}

If the book does say that then it is incorrect.

Gavin Deane

[AnalogFile]

Gavin Deane wrote:
....

if ( g() || h() )
{
//We don't know which functions were called
}

If the book does say that then it is incorrect.

On the contrary: it is very correct.

If both the functions were always called then there'd be no doubt.

But in C++ there's a sequence point implied in the || operator.
Therefore g() is called for sure, h() is not as it's called iff the
return of g() is false.

Since you do not know whether h() was called, "We don't know which
functions were called" is true.

[Ben Pope]

AnalogFile wrote:

Gavin Deane wrote:
...

if ( g() || h() )
{
//We don't know which functions were called
}

If the book does say that then it is incorrect.

On the contrary: it is very correct.

If both the functions were always called then there'd be no doubt.

But in C++ there's a sequence point implied in the || operator.
Therefore g() is called for sure, h() is not as it's called iff the
return of g() is false.

Since you do not know whether h() was called, "We don't know which
functions were called" is true.

It is possible to know. The behaviour is defined.

"I can't be arsed to work out which functions will be called in this
particular case" is not the same as "it cannot be determined" or "it
might be different next time".

I'm not sure where "we don't know" comes into that, nor do I care.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Gavin Deane]

AnalogFile wrote:

Gavin Deane wrote:
...

if ( g() || h() )
{
//We don't know which functions were called
}

If the book does say that then it is incorrect.

On the contrary: it is very correct.

If both the functions were always called then there'd be no doubt.

But in C++ there's a sequence point implied in the || operator.
Therefore g() is called for sure, h() is not as it's called iff the
return of g() is false.

Since you do not know whether h() was called, "We don't know which
functions were called" is true.

"g() is called. We don't know whether h() is called." would have been a
better comment.

I was responding to this statement from Tomás

<quote>
I'm open to correction, but I'm 90% certain that I read that the order
of
evaluation is undefined, and thus that "i == 1" could still be
evaluated
before "func1()", even in the example you give.
</quote>

The comment, "We don't know which functions were called", in the code
above is ambiguous. It could be taken to mean the order is unspecified
and that whichever function is called first (which we couldn't know for
sure), the second might not be called at all. Or it could be taken to
mean what you say. The first interpretation, which I took it to mean,
otherwise why was Tomás quoting it, would back up his statement, but
would make the comment incorrect. The second interpretation would, as
you say, make the comment correct, though somewhat carelessly worded.

Gavin Deane

[Tomás]

5.14/1

The && operator groups left-to-right.
The operands are both implicitly converted to type bool (clause 4).
The result is true if both operands are true and false otherwise.
Unlike &, && guarantees left-to-right evaluation: the second operand is
not evaluated if the first operand is false.

5.15/1 says similar for ||

1.9/18 states that there is a sequence point after evaluation of the
first expression.

Stand corrected.

-Tomás