It was satire guys

>runtime-expensive generics
>C#

Yes

I know for a fact that interface{} is runtime-expensive. Same flaw as a void*. I don't think Go2 generics are compile time.

C++ and Rust will retain supremacy in performance.

can someone explain what "cat -v" means or is a reference to

How is void * expensive? Not wanking on C or Go, just curious.

Its a reference to guys dressing up in fursuits.

5 is less than 9 but still a prime number, thus respecting their belief that cats are more valuable than humans.

What's the runtime overhead of c# generics?

Why is this so familiar?

Not only expensive but also unsafe
quora.com/What-are-the-disadvantages-of-void-pointer-in-C-language

Quija board

It's not

Because they inherit from object in runtime. Whereas C++ templates are generated in compiletime.

Because when he killed himself there were a lot of threads on Jow Forums about how much of a faggot he was and how the entire harmful software thing was a meme.

The return value of a function that returns a void pointer has to be checked with different possible types, which is inherently more expensive because you loose type information.

Is there anything wrong there?

Makes no sense. There is no overhead. Even when calling the 3 functions that they "inherit" aslong as you don't cast to object, which you wouldn't do anway because then you lose static typing.

>There is no overhead
Runtime inheritance IS overhead. These virtual methods come with cost and C# generics are thus not suitable for real-time computing. Three is a reason why C++ beats the living shit out of C# in any benchmark any time.

They are not virtual, even value types have these functions, they are compiler generated.

All inherited methods are virtual.
That's just how OOP works.

>All inherited methods are virtual.
That's just how OOP works.
Not if these functions are part of the framework and the framework always knows about them

What? Maybe in Java, but in C++ virtual functions need to bw explicitely declared as such. "Normal" inherited functions are known at compile time and thus cause no overhead.

Why are you desperately trying to deflect any obvious lacking of C#? What kind of autistic shill does that?

Anyways, """part of framework""" or not, your inherited virtual methods, runtime typeinfo and inheritance from root object aren't going to change. C# generics are just OOP polymorphism in disguise unlike compile-time generated codes of C++ or Rust. There is no room for argument left here.

huh? What do you mean?
template auto fn(T&& arg) -> there is nothing virtual going on here. Because T and U do not derive from root objects like C#.

harmful.cat-v.org/cat-v/

>Its a reference to guys dressing up in fursuits.
oof

harmful.cat-v.org/cat-v/

Go2 generics are runtime generics.

>is an admittance of defeat, and the fact that generic programming is an actually useful feature

"Many people have concluded (incorrectly) that the Go team’s position is “Go will never have generics.” On the contrary, we understand the potential generics have, both to make Go far more flexible and powerful and to make Go far more complicated. If we are to add generics, we want to do it in a way that gets as much flexibility and power with as little added complexity as possible."

well. dropped. what's the fucking difference with null interface then?

>Anyways, """part of framework""" or not,
>and inheritance from root object
As I said, it's no problem

> your inherited virtual methods, runtime typeinfo

This has zero virtual method calls as the type is known at jit compile time even though it is uses methods defined by an interface:

Public Interface IOrderedCalculator(Of TOrdered, COrdered As {IOrderedCalculator(Of TOrdered, COrdered), New})

Function Greater(left As TOrdered, right As TOrdered) As Boolean

End Interface

Public Structure Ordered(Of TOrdered, COrdered As {IOrderedCalculator(Of TOrdered, COrdered), New})

Private Shared ReadOnly Calculator As New COrdered

Public Shared Operator >(ByVal left As Ordered(Of TOrdered, COrdered), ByVal right As Ordered(Of TOrdered, COrdered)) As Boolean
Return Calculator.Greater(left._value, right._value)
End Operator

End Structure

Mostly true. But he did make a solid point about simple, clean, frugal code that should be applied real world in the programming community.

Is
-> a return type hint or whatever it’s called?
I didn’t know you could do that.

>
Sorry I meant just U
Yes, C++11's trailing return type

I just assumed it was wierd syntax specific to that case and it was down to ISO autism.

Go2's generics proposal is bad.

The semantics of Go2's generics are deliberately vague so it may be implemented either way.

dwm is still fun to use.

made me kek

>generalize an algorithm
>specialize for every case
why generalize in the first place then

>>specialize for every case
"no"

ed boon.. no

If you already know the type, then you don't need to check shit.

newfag here, who is he?

Attached: 1537566634658.png (440x500, 204K)

Ironic shitposter "living" now with Terry, the edgelord.

what's his name?

uriel.cat-v.org/

you mean in C# virtual functions need to be declared
inherited functions are not virtual by default in C#

Think about reflection and such.

Which you don't, in case of void*

Don't you fucking dare put that cocksucker on the same level as the Prophet.

Why would you care about reflection in performance critical code?

No one uses C# in performance critical code. That's alight.

Because in some cases - like custom dispatch - the alternatives are much worse. And unfortunately, everything C# offers in terms of metaprogramming is like that.

>and Rust
I love this meme

I will never get tired of this image.

>reflection
>custom dispatch
I don't know what your goal is but generics don't have runtime overhead.

When do you ever do this check anyway? You either lose the type information when passing pointers as void* or you cast them to a specific type when you assign them to non-void pointers.

his name is uriel.
he was right.

No he wasn't.

how dare you!

Attached: bell.png (853x621, 106K)

>C# generics are just OOP polymorphism in disguise
You are talking about java type erasure. C# has actual generics.
For more info:
stackoverflow.com/a/41464329

Saved.

Funny because all of 9front is gommie or at least cryptogommie.

Where is the contradiction? Gommies are delusional retards.

Who is Stanley Lieber?

>linking a quora article

Attached: badass.jpg (300x226, 21K)

If Uriel saw this he would kill himself again.

This article implies otherwise:
alexandrnikitin.github.io/blog/dotnet-generics-under-the-hood/
The JIT compiler bug aside, it likely means you have to decide between having a JIT compiler or doing away with reflection.

All C needs is proper generics and then it's the perfect, I'm currently using preprocessor to to do generics but it's messy and doesn't work when you just have as a library, you need the .c code if you want it to work

>All C needs is proper generics and then it's the perfect,
>shit tier declarations
>decaying array jokes
>textual inclusion
>half-broken standard library
>computed gotos and other useful platform independent stuff not standard

>that
>article

Attached: 1537975511081.png (211x239, 5K)

Give me one quote by Go devs saying the reason Go 1 doesn't have them is bloat.

Reasons to use the GPL over MIT or BSD:
• FUCK YEAH I WANNA BE A GNU-MALE TOO LIKE STALLMAN HAHAHA ABOLISH PRIVATE PROPERTY AND BAN PAY TOILETS
•...

>shit tier declarations
It's fine and simple, dumb brainlet
>decaying array jokes
C doesn't need dumb bloat that adds nothing to it
>textual inclusion
Absolutely nothing wrong with this, it's old school and has learning curve but it works well
>half-broken standard library
You can literally go on on github and just use some other library or you can implement one yourself, not a issue at all
>computed gotos and other useful platform independent stuff not standard
Well no shit platform specific code isn't portable, it's not part of the standard

>>decaying array jokes
struct Array {
char *array;
int size;
};

struct Array *create_char_array(long long unsigned int size)
{
struct Array *set;

set.array = malloc(size);
set.size = size;
return set;
}

void del_char_array(struct Array *set)
{
free(set -> array);
}

>>half-broken standard library
nothing wrong with gets()

>struct Array *set
declared as a pointer
>set.array, set.size
won't compile, because set is a pointer.
besides, set hasn't been initialized to anything yet.
using a variable that hasn't been initialized is undefined behavior.

>struct Array
>int size
>create_char_array
>long long unsigned int size
that's basically asking for trouble.

>set -> array
I've never seen anyone write the arrow operator like that.

He was right though

does not really beat the point though, i went ahead and created another function in the process, should compile with no warnings.
#include
#include
#include

struct Array {
char *array;
int size;
};

struct Array create_char_array(long unsigned int size)
{
struct Array set;

set.size = size;
set.array = malloc(size);
return set;
}

struct Array create_char_array2(char *str)
{
struct Array set;

set.size = strlen(str);
set.array = malloc(set.size);
strcpy(set.array, str);
return set;
}

void del_char_array(struct Array *set)
{
free(set -> array);
}

int main(void)
{
struct Array sentence = create_char_array2("ur a fagget");

printf("the sentence \"%s\" has %d characters.", sentence.array, sentence.size);
del_char_array(&sentence);
exit(EXIT_SUCCESS);
}

>set.array = malloc(size);
That's wrong. I'll let you figure out why, I stopped reading here btw

does not beat the point either, but now that you insist
it is bad practice to use malloc() within functions, since it is easy to lose track of the state of memory - SAVE for a few, rare exceptions, this being one of them.
the function does not check for a case where malloc returns NULL
this is a design argument