Hey C faggots. What meme is this? Why do i have to tell my code

> Not using array of function pointers to handle math.

lel

brainlet.

#include <standardfeaturesinanymodernlanguage>
#include <youhavetoputdotHattheendofthisonebecauseyes.h>

int void_ shittyparams(char becarefulbecauseifyouarentcarefulthecharmightbreak){
C is the best language!
}
}
}

}

If you don't use 'break' then it will keep checking every single condition which can lead to bullshit. But you might want it to do that, so it just makes more sense to have 'break' then 'notbreak.'

>>61664433
>return in every case
All of those breaks are unnecessary

>return before break
Oh no

>>61664433
>fuck c
Thats not C's fault you ignorant nigger, its actually a feature you can use. That's how assembly works.

>>61664541
this. never have multiple return statements in a function, talk about nasty shit.

>>61664622
>use language that allows x
>hurr don't use x

Anyone has a link for that Terry's Holy C video where he describes the switch extension where you can put instructions into the middle and claiming that he is a genius for improving C?

>>61664657
the story of C++

>>61664622
>never have multiple return statements in a function
Fuck off. Just because you can misuse multiple return statements doesn't mean you should never use them. There are plenty of times where multiple return statements are fine

>>61664433
While it may be a force of habit to use break at the end of every case statement, you don't actually need to do it if the code is unreachable, such as when you are returning beforehand.

>>61664622
There is absolutely nothing wrong with multiple returns.

>>61664433
Actually makes sense when you're coming from assembly

Programming. Top kek. I used to do that shit in college, fucking boring.

t. Sys Admin at IBM.

>>61664874
This programming is the most boring thing.
T. Electrical engineer

>>61664722
>>61664657
>t. never been employed

>>61664452
This is surprisingly the fastest way to do things, easily beating out optimized branching code.

I'd like to see perform characteristics with the new ryzen predictor

>>61664938
Wouldn't you incur a pipeline flush EVERY time you use something like that?

>>61664986
>flush
Sorry, meant stall.

>>61664874
If programming seems boring to you, then you're not a true nerd. And I mean that honestly.

>>61665017
You'd think, but I recently read somewhere about how optimized modern x86 is for OOP based programs. This just hits the same thing that determines dispatch target for virtual functions in the pipeline, which is super optimized. So your stall is determined far in the future by possible jump targets instead of branch flags in the current instant.

In general, it performs almost equivalent to perfect branch prediction, and always better than failed predictions

>>61665077
kek im a genius and i didn't even knew

>>61665077
That makes sense. Thanks, I'll read into it. It does seem logical to optimize such indirections away, seeing that dynamic dispatch is everywhere today.

>>61665153
Yeah... Downside is it makes all but the most Enterprisey bullshit completely unreadable, since you have to pre-calculate your jump condition as an index into a jump table

File: 1379690970603.gif (973KB, 500x360px) Image search: [Google]

973KB, 500x360px

>>61665153
>im a genius
Yes, Billy, we know you mom calls you a genius.

>>61665182
I guess I should be saying, this is really something the compiler should be doing where possible on -O2

>>61664622
>pascalet