38

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?

Comments
  • 14
    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; }
  • 3
    There actually is the anti if movement. And depending on the conext I believe switch and if are actually satements we should avoid
  • 5
    if archaic() {
    return dontUse()
    }

    Oh... Wait...
  • 2
    @host127001 Sure, there are times where you can legitimately use too many ifs. But those are reasonable concerns. This guy wasn't reasonable. 😆
  • 8
    He is right! Legends do this:

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

    You're welcome!
  • 3
    @mohammed That certainly gets rid of them.
  • 3
    You can usually replace switch statements with polymorphism.

    This is also interesting:
    http://degoes.net/articles/...
  • 5
    Does he have any idea how much faster jump tables are than 40 fucking branch instructions? Who fucking cares if it’s archaic computers are archaic at this point.
  • 3
    @R01101111bert no you cannot, because polymorphism relies on virtual functions which translates into function pointers and a switch is a jump table. One is decently fast and one is extremely fast.

    @mohammed some people use this pattern to implement “finally” in c++. It ain’t pretty, and I don’t like it, but it does serve some purpose crazy as it is.
  • 0
    @FrodoSwaggins I think on the JVM polymorphism would reduce the size of the method, which could lead to both of them being inlined.
  • 1
    @R01101111bert I’m not sure what case you’re referring to but I’m not terribly convinced yet. I will say generally that’s not the case, because where function gets inlined then another will not. The indirection still has to take a hit.
  • 1
    @FrodoSwaggins is bringing the sanity of reason yet again.
  • 0
    @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.
  • 0
    @R01101111bert i wasn’t using the term case in a technical sense

    Also; virtual functions by their very definition can not be inlined. A function must not be virtual in order to be inlined. You may have misunderstood the article.

    Think about it... if you don’t know what the function pointer is at compile time, how do you inline it? For the finale try to compile c++ code with “virtual inline” keywords, and the compiler will simply ignore the inline keyword (since its syntactically only a suggestion) and tell you so in the stdout messages.
  • 1
    @Root I had to take a break for a while.
  • 1
    @FrodoSwaggins I missed you 🙁
  • 0
    @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.
  • 1
    @R01101111bert it wasn’t a pun. It’s an English word you know, and it is in the dictionary. I used it very literally.

    In the case of c++ or JIT, those cases are more limited than you think. Unless the class was instantiated in the current function, generally speaking it isn’t going to happen. In a JIT, if you use check type information in active memory then you just did a bunch of branch control which is crazy slow, and then you can generate static code if you want, but you lost this benefit already. If it’s easy to determine the runtime type at compile time, then the virtual indirection isn’t really serving much purpose. It’s extremely rare that software uses virtual functions in this sense.

    In fact the situation you have supposed where we use virtual indirection to dispatch control there is literally no way that it can do it at compile time, by the very definition.
  • 2
    @FrodoSwaggins @R01101111bert Not a pro here, but it seems to me that refactoring a switch case into polymorphism isn't something that should happen a lot if the thinking step was done correctly in the beginning (of course, adopting a behavior depending on the value of a "type" variable should ring a bell in every OOP programmer's mind). However there is still cases were switch or if's are unavoidable, in basic logic stuff like "if the value is odd, do this, else do that".
    Coexistence of well used polymorphism and conditional statements is logical...
  • 1
    @Brosyl I don’t disagree with that.
Your Job Suck?
Get a Better Job
Add Comment