• 9
• 9
• 9
• 10
• 10

# Is using one the switch statement better then using multiple if statements?

This topic is 660 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I am currently learning C++ and I was just wondering if using the switch statement is better and/or a better and more efficient way of using multiple if statements? Is there advantages to using multiple if statements? If there is what are they?

Are switch statements good in game development?

I am just curious as I am learning C++ and I want to get my knowledge banks stored up :P

##### Share on other sites

Better how? Switch-statements can be way faster then if/else-chains, specifically if there are many items to check for.

The compiler is free to optimize the switch-statement as he pleases. For a small number of items, the compiler might just produce an if/else-chain in the background. However, if you have like say 20-30 items, then the switch can ie. be converted to a table-lookup, which is way cheaper than having to check perform up to 30 if-conditions.

A reason for using multiple if/elses is mostly if you cannot use a switch, ie. if you are comparing strings, or other non-literal types.

But keep in mind that unless you are calling that block of code many many times per frame, this won't matter at all. At this level, always prefer code clearity over performance. So if you are asking if switch-statements are better in this regard: Largely depends. For many items, switch can easily be more readable, and safer (since you cannot accidentially check for the same item multiple times).

However for just 1 or two items, if/else tends to be more readeably, if not for being shorter. Consider this:

if(x == 2)
foo();
else
bar();

// switch is moar awesome!

switch(x)
{
case 2:
foo();
break;
default:
bar();
break;
}


So to sum up, both have their uses. Worry only about efficiency if you know you are working on performance critical code and/or  if you did proper benchmarking. Otherwise, choose whichever is more appropriate to the situation in terms of readability and clearity - just don't got around and throw switch-statements at every single if-statement and you should be fine :)

Thanks, that gives me a lot better understanding of it! :)

##### Share on other sites

Modern compiles are not so stupid, however. Example: https://godbolt.org/g/i5NBKH Note that foo() and bar() are both compiled into jump tables despite one using a switch statement and the other an if-statement chain.

Doesn't seem to be the case for GCC and MSVC.

##### Share on other sites

Better how? Switch-statements can be way faster then if/else-chains, specifically if there are many items to check for.

The compiler is free to optimize the switch-statement as he pleases.

The compiler is free to optimize almost anything as it pleases. There is absolutely nothing whatsoever that specially allows a switch statement to be better optimized than if-statements.

Older compilers _wouldn't_ optimize the if-statements as well, but that was a technology limitation. The switch statement is easier to recognize as what it is, while slightly more clever analysis is required to determine that a series of if-statements can be similarly optimized.

Modern compiles are not so stupid, however. Example: https://godbolt.org/g/i5NBKH Note that foo() and bar() are both compiled into jump tables despite one using a switch statement and the other an if-statement chain.

Thats neat, didn't know that, yet as been said MSVC isn't that clever (thats where my assumption originally came from).

There appears to be one case for a switch being faster/less assembly even on clang though, that is if you can tell the compiler that the default-case will never be hit (by replacing return 0 with __builtin_assume(0)). This gets rid of four lines of assembly in your example. Doing the same with if/else-chains doesn't work, and so I quess if you are working on a real tight loop that switches on a value within a known range (like an enum class), than this can still be a point for switch (unless there is a way to get clang to emit the same assembly for the if/else-chain).

##### Share on other sites

Better how? Switch-statements can be way faster then if/else-chains, specifically if there are many items to check for.

The compiler is free to optimize the switch-statement as he pleases. For a small number of items, the compiler might just produce an if/else-chain in the background. However, if you have like say 20-30 items, then the switch can ie. be converted to a table-lookup, which is way cheaper than having to check perform up to 30 if-conditions.

A reason for using multiple if/elses is mostly if you cannot use a switch, ie. if you are comparing strings, or other non-literal types.

First, you misslead the readers on what switch is. Since switch is named so improper, switch is not a switch, unless there is break keyword instruction in every sub-block of condition .
What switch does is that it evaluates all conditions in their order and executes their subblock if they are true. Logicily switch is equal to this

{// the escape block

if (A){}

if(B){}

if (C){}

{} // the default:

}

If you are sure that A and B and C will always be exclusive by being true, break will save you of only their conditional checks. You can omit default option, or place it in any roder, or you can break only in some code, not other, and create intent enigma hell for any reader of your code, as you have stressed readibility- there is no obvious readibility to switch (just a little hope there is break at every spot, or return, or continue).

Performance is a question of your run-time branching, performed instruction saves, navigating, not at all a question of wheather it was an if or a switch. But frankly, I cannot spot when and how switch can have outperformed proper conditionals in any way on any platform- and by my logic I conclude it cannot.

And to advice beginner programmers with switch for "readability", or "always use"- is a very bad service to them. I know we experienced programmers can even justify GoTo/Label, but doing so in production of your employer will get you fired. The paradox.