The dilemma of generic programming

Original article: http://research.swtch.com/generic

Common Data Structures (vectors, queues, maps, trees, and so on) seem to be a hot topic in evaluating a new language. One of the FAQs about the Go language is about generic programming in go. For generic programming, there are usually three processing methods:

1. (C Language) Abandon generic type. It's hard for programmers, but there's no need to add too many complicated things to the language.

2. (C ++ language) special compilation or a large amount of code. This makes the compiler suffer. The compiler generates a bunch of code, and most of the Code is useless. A good linker is required to clear duplicate copies. Generating a piece of code for each type may make the code efficient, but the program is a whole, which will cause unfriendly CPU cache. I have heard that after a simple library rectification and removal template, the size of the text segment (that is, the text segment in the file format of the Dynamic Link Library) is reduced from m to 10 K.

3. (Java language) implicitly boxed everything. This causes program execution to slow down.
Compared with C-language handwriting, C ++ compiler generation, Java code is the simplest, but the most inefficient, in terms of time and space. Because all operations must be implicitly packed and split. The space occupied by a byte vector container (vector <byte>) is much larger than that of every byte in a single byte. Hiding and unboxing can complicate the type system. On the other hand, this may be a user-friendly instruction cache, because it can separate a byte vector (vector <byte>) to write every byt e.

The dilemma of generic programming is: either programmers or compilers, or reduce the running timeliness rate.

========================================================== ==================

The original author is one of the implementers of the Go language.

From the FAQ of go, we can see that they are not eager to implement generics because they have not found a suitable implementation solution to solve the above dilemma.

Since go does not have generics, you can only use interfaces to implement common data structures. But from my perspective, the efficiency of interfaces in go is a little slow (slower than the virtual functions in C ++. Think about a vector container and call a get function, it is slower than calling a virtual function of C ++ ..).

So before go1.0, when there is a vector container, there is also an intvector and a stringvector. If I want to use a high-efficiency float vector, do I need to write a floatvector?

If go supports generics, it's a pleasure.