If statement question

If statement question

Falciase

Member #10,908

April 2009

Hello, I was wondering if anyone could tell me: in an if statement, when you have more than one conditionals joined by AND, if the first statement is false does it bother to check the others? Is processing time wasted, and therefor if statements with AND should be separated into two?

Surely it breaks out of the test, but I'm not entirely sure myself.

If I am not explaining this well, what I mean is, in the following statement:

#SelectExpand
 1bool jumping = false;
 2bool onGround = true;
 3if(jumping && onGround) doStuff();

Seeing that jumping == false, would onGround even be checked at all? Surely not, but I am not sure. Anybody know the answer?

____________________________________
Falcon Five's Development Site

Jonatan Hedborg

Member #4,886

July 2004

Easy to test. But yes, it will abort early.

Yodhe23

Member #8,726

June 2007

So "cascading" your conditional tests can "optimise" your programme?
I.e. place boolean tests before one with function calls etc?? Would it be
effective to roughly organise the probability of the conditional tests,
with the most likely to "fail" first going down to the least likely at the end of the statement?

www.justanotherturn.com

Audric

Member #907

January 2001

Yes, in C and many other language, the logical AND and OR operators are short-circuiting.
You won't find any C compiler where the second member of an "&&" is evaluated if the first was resulted in 0. It would be a critical bug.

Note that this matter mostly when the evaluation involves calling a function (onground()), or if it would do something invalid:

if (parent!=NULL && parent->Type==ENEMY) ...
if (divisor!=0 && height/divisor==1) ...

Yodhe23 : Yes, on all accounts. But don't over-do it... It's worthwhile to avoid expensive 1-N collision tests when (this->Is_ghost==true), but avoiding one mathematical comparison makes very little difference.

OnlineCop

Member #7,919

October 2006

Audric's reply is the best.

If you have this:

BITMAP *image = NULL;

if (image && image->w < 10) { ... }

short-circuiting will stop as soon as it encounters the "if (image)" portion of that statement. Otherwise, the "if (image->w < 10)" would cause a segfault.

Arthur Kalliokoski

Second in Command

February 2005

It's also a good idea to parenthisize defensively:

<code>
if (image && (image->w < 10) ) { ... }
<code>

They all watch too much MSNBC... they get ideas.

OnlineCop

Member #7,919

October 2006

if ((NULL != image) && (image->w < (9 + 2 - 1))) { ... }

Audric

Member #907

January 2001

Defensive is all right, but in this case I would rather recommend to learn the relative priorities of the most common operators.

Just need to know that there is no 'trap' in an expression like:

// Sprites are 32 pixels wide, only need to be drawn if some part is visible
if (x > -16 && x < SCREEN_WIDTH + 16)
{
   ...
}

Falciase

Member #10,908

April 2009

Thanks guys for your input. I was pretty much positive this was the case, as that would mean I had been taught wrong, and all other code I had seen had been wrong so I was pretty sure this was the case XD Assurance is good.

____________________________________
Falcon Five's Development Site

james_lohr

Member #1,947

February 2002

Yes; it's called lazy evalutaion.

Audric

Member #907

January 2001

The wikipedia article that I linked mentions a peculiar phenomenon:
(a > 0 && a < 10) would be slower than (a > 0 & a < 10) because of the branch (test+jump) it causes.

OnlineCop

Member #7,919

October 2006

I've never seen the use of the single & in the context you've described.

(a != 0 && a < 10) would be slightly faster, as the debate in the other thread regarding the > and != still rages on, but you're not going to be MUCH slower. Plus, with a few nano-seconds in the use of just a handful of evaluations isn't going to up your performance. You'll only see increases when you're dealing with thousands or more iterations.