*goes fast*

*goes fast*

Attached: c.png (564x599, 35K)

>fast with virtualization overhead

Don't forget the sound engine.

Attached: sound engine meme.jpg (403x431, 46K)

Attached: 516R4ZoMqBL._SX402_BO1,204,203,200_.jpg (404x500, 35K)

*goes fast securely*

>C
>fast

Attached: 1531760424812.jpg (750x728, 270K)

>c
>not fast

Question about Go: What are generics and why does everyone shit on Go for not having them?

still slower than proper C++ though since it lack r-value copy constructor and assignment and function pointers generate slower code than function objects

>overflows

In an undefined direction?

Think of C++ templates and Java parametered classes. Because people want a spoonfeeding language that does everything for them. You could literally use C's preprocessor directives and `gcc -E` in your Makefile to give Go code generics.

please tell me more about how is juggling with void pointers and size_ts good for anything

Attached: c-vs-cpp.png (712x112, 15K)

>*goes fast securely*
>Go
Kek

>go
>*goes*
shut up with these puns

Holy fuck based

Come on d0de, that is just a shitty implementation of quicksort.

>use gets() and memcpy()
>no garbage collection - dangling pointers everywhere
>be slightly faster than languages that are way more secure

millisecond difference is not so fast

no, c's quicksort has to use indirection while c++ can inline the comparison function at compile time because it has type information

>>use gets() and memcpy()
there is nothing wrong in memcpy()
>>no garbage collection - dangling pointers everywhere
Well, if you shit on your floor, there is going to be shit on the floor. L2takeresponsibility.
>>be slightly faster than languages that are way more secure
It's not even that fast in all cases. It really depends.

>qsort vs std::sort

Attached: brainlet27.png (1066x600, 252K)

>trying to bench mark different languages
>gcc keeps optimizing everything out to 0ms
c pls

>L2takerespondibility
>abiding someone else's dodgy rules

>having collection of at least 27 brainlet pics
>compensating this hard

yeah that's the curse of optimizing out unused result
would assigning result to volatile variable work?

It's when a class is written in a generic way, meaning it takes a parameter of type T and does something with objects of that type depending on what the type is. Common example is a List in C#. You can instantiate a List, List, List and regardless of the type you can call the List instance's methods in a type safe fashion, e.g. the Add method of a List takes a string as a parameter. List has a method Add(int element). Basically the list is written in such a way that it doesn't care what type you instantiate it with, but then all its methods and members use that type. One implementation for parameters of multiple types while ensuring type safety.

I don't think it is a big deal because compilers are good enough to inline function pointers.

(evidently not)

>he doesn't collect brainlet wojaks

Attached: brainlet62.png (538x421, 54K)

that's not fortran

>work in complex environment, C for language Perl for tools
>write some C stuff which loads fonts and converts text into header bitmaps for faxes, mallocs space needed, frees it after
>"yeah, some code runs on systems where we can't dynamically allocate memory"
Took a bit to re conceive how I was going to do it, with some advice on loading the data in an attachable, regular way.

Attached: t4.png (1319x1252, 153K)

>no garbage collection - dangling pointers everywhere
that's your own fault, it isn't hard to manage your memory correctly

>be slightly faster than languages that are way more secure
let me know when I can put Go on an 8051 and have it not immediately come to a screeching halt

>implying anyone calls a sorting function in real-world code

>C is slow guys!
>comparison is based on using different algorithms making the entire experiment bogus

In reality if you cared about sorting performance and doing it in C you wouldn't be using a generic function like qsort where you don't even have control over what sorting algorithm it does. Your entire point is moot as it's comparing algorithms rather than actual performance when the code is exactly the same.

>function pointers generate slower code than function objects
oh please

"If you have to argue, then you already lost."