Why are if statements bad again?

Why are if statements bad again?

Attached: EYGK7MRXgAAAxpW.png (1127x1191, 51.73K)

Other urls found in this thread:

en.m.wikipedia.org/wiki/Branch_predictor
twitter.com/AnonBabble

If statements aren't bad, but they can be used inappropriately.

who said they are?
but sometimes other flow control structures are nicer

switch > if

This is true for C and C-likes but in javascript it's actually slower for less than 3000 cases.

Makes no difference with modern compilers

Dictionary

If you wanted to perform a third action on a different type you’d have to paste it into each section.
These things are all the same, but I had to read 30 lines to make sure that was right. Including looking stuff font size etc closely.

It's more about readability
for big if-else chains I'd rather read and write a switch or a match statement than a big if else chain

switch (a)
case only_thing:
waste_of_time()
break
default:
more_waste_of_time()

Hashmaps are silly when you're dealing with a known set of data. A simple array indexed via enum is a lot faster.

>a lot faster
>O(1) vs O(1)
It would be hard to fuck up this part of the code so badly that performance is an issue.
It doesn't matter which data structure you use (O(n) is easily fast enough here) so long as you get rid of repeated logic.

Seems like this could have been solved with an object/enum/dictionary or whatever it's called in your programming language. It would move all this "if" code elsewhere and make your function more readable and easier to maintain.

has c++ finally added the ability to switch on strings yet?

This. If you find yourself using a large if/else chain, you may be using the wrong abstraction. Switches are nice, but even a large switch may be the wrong choice.

Because they're more verbose than a swtich statement when every condition checks the same variable for different values.

If the compiler decides to use a jump table to compile the switch statement, the if statements will also be slower

Use a hash function to convert the strings to numbers. Or you can store 4 characters in an int using a reinterpret typecast.

a lot of compilers implement switch statements with a lookup table, so it's going to be a lot faster for low level languages. as for something like Javascript, this user is right, but it still looks a little better. And some languages just don't have a switch or match equivalent, so you have to have an if-else forest.

If your switch statement is really huge, you can substitute polymorphic classes for it. So each class overrides the class method to contain each switch case's code.

That approach needs a lot more boilerplate code though and also is harder to read (the flow of execution will jump between lots of different methods). Not worth it for a small set of cases.

That depends on the JavaScript runtime used. You'd have to profile your usecase (if you care that much about performance of a switch statement)

if statements are bad, goto is bad, switches are bad, functions are bad, typing is bad, computers are bad, monitors are bad, electricity is bad.
everything else though is golden.

en.m.wikipedia.org/wiki/Branch_predictor
Basically, there's some circuit that tries to "guess" whether a program should take a conditional jump when a branch instruction executes. It can improve performance slightly if the prediction is correct. Mispredictions waste a lot of CPU cycles, however. This goes for both "switch" and "if." A compiler might optimize branches out for you by using jump tables and such.

Like most things in life, it depends on what you're trying to do

If given the opportunity, I will always write switch statement or expression over if/else.

I just find it more visually appealing and I don't about the irrelevant performance result of it.

Attached: b0e.jpg (656x679, 30.74K)

C++ is getting match instead which is much better

Right answer. But know switch statements can be faster