Quote:Original post by nb

Quote:Original post by samoth

Quote:Original post by nb
some compilers / compiler settings actually do the if statements either way you suggested. They can be set so that they stop checking once a section of the if statement fails, or they can check the entire expression regardless of if any have already failed or not.

Careful, though. This may be a "speciality" of Delphi (don't know anything about Delphi really).
In C/C++, it is clearly against the standard (you are guaranteed that the right side of && will not execute if the left side is false), and any compiler implementing it differently is broken. I wouldn't want to use a compiler that lets you customize such a behaviour, since many programmers indeed rely on that assertion, so it may break code that's perfectly valid.

i did say 'some'. as a default delphi does not check all statements if one is already found to be crap. i'm sure there's a reason why it can be toggled to do checks on all statements... maybe something to do with being able to debug values that it would otherwise trash and render un-readable when it got to the if statement. don't know. all's good.

Quote:Original post by Hodgman

Quote:Original post by Driv3MeFar
The same happens with the statements in the first if block you posted. Logical operators like && can be short-circuited, such that when it becomes impossible for the whole statement to be true, the rest of it is not evaluated.

^^^ Take this knowledge on board if you do want to optimise your if statements at some point.

Lets say for example that Test#1("player.IsAlive()" ) takes 5ms to execute, but Test#2("player.GetTeam() == 2") and Test#3("player.GetHP() < 75") only take 1ms. (I know these numbers are absurd, it's just for illustrative purposes!)

To make your loop as fast as possible, you should order these tests within the if from fastest to slowest. i.e.:

if( player.GetTeam() == 2 && // 1ms    player.GetHP() < 75   && // 1ms    player.IsAlive()       ) // 5ms

This way, if either of the fast tests return false, then the slow test will never be executed. I.e. it only calls the 5ms function on objects which have passes the quick tests.

Quote:Original post by Rydinare
Having said all that, on a slight tangent, if it's common case that you're checking for the same few conditions in multiple areas, I would advise making a utility function that checks all three, to keep the client code a bit cleaner.

Something like:

*** Source Snippet Removed ***

I do think that may help readability. If the condition is only tested in one place in the code, then this may be overkill.

void Player::heal(){    strength = 100;}void Player::update(){    if (shouldHeal())    {        heal();        raisePlayerHealedEvent(this);        /* or something... */    }}bool Player::shouldHeal(){    return (IsAlive() && ..);}

Quote:Original post by WanMaster

Quote:Original post by Rydinare
Having said all that, on a slight tangent, if it's common case that you're checking for the same few conditions in multiple areas, I would advise making a utility function that checks all three, to keep the client code a bit cleaner.

Something like:

*** Source Snippet Removed ***

I do think that may help readability. If the condition is only tested in one place in the code, then this may be overkill.

I agree. One might even consider to keep the check inside the class itself. YMMV of course.

*** Source Snippet Removed ***