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:

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

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

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?

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.

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.

It's also a good idea to parenthisize defensively:

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

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)
{
   ...
}

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.

Yes; it's called lazy evalutaion.

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.

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.