One day, this ex-boss of mine dropped the following bomb:

“Stop using switch statements, the switch statement is archaic.”

The if statement should be even more archaic, right? So, should we stop using ifs as well?

Upcoming C++42 and Java 13 will put things right with new keywords "although", "elsewise" and "failing_this":

You can then avoid if-else by writing

although( x == 42 ) { doStuff(); }

elsewise( x == 666 ){ doOtherStuff(); }

failing_this{ doWhateverStuff; }

There actually is the anti if movement. And depending on the conext I believe switch and if are actually satements we should avoid

if archaic() {
return dontUse()
}

Oh... Wait...

@host127001 Sure, there are times where you can legitimately use too many ifs. But those are reasonable concerns. This guy wasn't reasonable. 😆

He is right! Legends do this:

while(condition){
...
...
...
break;
}

You're welcome!

@mohammed That certainly gets rid of them.

You can usually replace switch statements with polymorphism.

This is also interesting:
http://degoes.net/articles/...

@FrodoSwaggins I think on the JVM polymorphism would reduce the size of the method, which could lead to both of them being inlined.

@FrodoSwaggins is bringing the sanity of reason yet again.

@FrodoSwaggins I wasn't referring to a case because I've replaced it with a method.

I think:
If the virtual function is inlined the code is already faster than a jump table. Inlining the outer function could also be possible (MaxInlineLevel = 9).

I don't know much about this stuff, so this could be wrong. My original point was that polymorphism is often easier to read and I really don't care if it takes a nanosecond longer to call a function.

@FrodoSwaggins I missed you 🙁

@FrodoSwaggins Case was a really bad pun...

JIT compilers can know this stuff at compile time. For example the code inside a loop can be replaced with a better version after collecting statistics for a few iterations. I guess the C++ compiler can also figure out the exact class in some situations.