[mikepurvis]

At least in C++ there's also the matter that the type switching happens at compile time, not runtime. You get a new instance of the function for each type that it's called with.

That's why C++ libraries with generic interfaces need to have their full implementations in the header or else have explicit instantiations for known supported types. If you compile the library first and the project later, there's no way of knowing at library-compile-time which instantiations of the generic will later be needed, and like, the types might not even exist yet at that point.

[p0w3n3d]

You're right, C++ generic implementation is different than Java for example. That's why it was hard for me to nail the features the generic should have in general... C++ is more like duck typing with precompiled checking i.e. If you have no traits you still get integers summed for example because the generated code from the headers is compilable. On Java it's different: all the generics have types erased and there is typecasting later, unless they are inherited by other types

[mikepurvis]

I'm not a Java person, but my understanding is that in Java everything is boxed anyway, so the implementation of the "generic" logic is always just dealing with a pointer-sized entity and it's a matter of whether the dereferenced object on the other end of that has the required fields/methods.

[renox]

> Java everything is boxed anyway

Not true, there's int and Integer.

[mikepurvis]

Right but you can’t use them as type arguments to Java’s generics so they’re not really relevant in this context.