GML Evaluation Order

samspade

Member
I have a question about the evaluation order of if statements. I have been using statements like:

Code:
if (instance_exists(target)) && (distance_to_object(target) < range) {
    /* do something */
}
in code rather than:

Code:
if (instance_exists(target)) {
    if (distance_to_object(target) < range) {
        /* do something */
    }
}
because the first form was easier for me to read and saved on indentation. I tested it and it wasn't giving me an error if the instance didn't exist so I assumed that it evaluated the if statement in order and (at least for an &&) therefore wouldn't check the second half of the if statement if the first half returned false.

However, I was reading the help manual about evaluation order and it seems like this may not be true on all platforms. Should I always use the second ordering or are the two forms identical?
 
I

Insanebrio

Guest
Use the second: its more safe and also nested ifs uses less cpu than using operators (just a very little)
 

TheouAegis

Member
Well they made short circuit evalutations standard in Studio 2, so maybe it's okay now. I was having issues finding any documentation about it not working on certain platforms.
 

CMAllen

Member
Use the second: its more safe and also nested ifs uses less cpu than using operators (just a very little)
This isn't entirely accurate. Depending on the operations, the CPU can evaluate a series of conditionals in a single go, whereas with multiple nested if statements, each conditional must be evaluated one at a time regardless. That being said, I know that GMS2 does, as TheouAegis mentions, short circuit evaluations, while in older version of GM, an entire if statement had to be evaluated regardless of if a conditional made the if() branch false. So this sort of a difficult topic to cover properly. It's more of an 'it depends' situation.

Regardless, one thing IS for certain -- check your LEAST computationally complex conditionals first, leaving your most complex conditional checks for last.
 

zendraw

Member
even if &&`ing is applied on all platforms, id still use nested ifs, its more readable and flexible, i aways find the need to modify an if the more i progress with a project, and to turn a chain of &&`s into a nest of ifs, is just a waste of time. for optimisation, you shuld nest the most light check first, or if you use &&`s you shuld put it infront, otherwise use the most compatible.
for me, if somthing throws a small impact on performance, i go with whats most compatible, otherwise, whats most optimal, but i dont think you will get in a situation where you need to choose the most optimal for the sake of compatibility. atleast i havent. maybe with surfaces and dealing with files you will get in such situation.
 

dannyjenn

Member
I'd just like to point out, the nested if statements are not always a good substitute for the &&.

Suppose you were doing something more complicated, such as:
Code:
if(a&&b){
    // one
}
else{
    // two
}
If you want to re-write that as nested if statement then you need to do this:
Code:
if(a){
    if(b){
        // one
    }
    else{
        // two
    }
}
else{
    // two
}
which is a lot more difficult to follow than if you were to just use the &&.

And that's just with a single else statement added. Suppose you were trying to do something even more complex, like this:
Code:
if(a&&b){
    // one
}
else if(c&&d){
    // two
}
else{
    // three
}
Try doing that with nested if statements and it quickly becomes nothing but an illegible and inflexible mess.
 
Top